Search

622 results for “aro”

Dev Community @[email protected]
2026-10-27
The Need for Speed: Unlocking Your Website's Potential with the Critical Rendering Path

Ever felt that pang of impatience waiting for a website to load? You know, that agonizing moment where the screen is just a blank canvas, and you start questioning your internet connection, your life choices, anything to explain the delay? We've all been there. In the blink-and-you'll-miss-it world of the internet, speed isn't just a nice-to-have; it's the make-or-break factor for user engagement, conversion rates, and even your search engine ranking. And at the heart of this speedy performance lies a concept called the Critical Rendering Path (CRP).
Think of your website as a delicious cake. To bake that cake and present it to your eager guests (your users), you need a recipe. The CRP is essentially the most efficient recipe for building your website's visual representation on the user's screen, as quickly as possible. It's about understanding the essential ingredients and the most direct steps to get that cake out of the oven and onto the table.
This article will dive deep into the fascinating world of the Critical Rendering Path. We'll break down what it is, why it's so darn important, and how you can optimize it to make your website lightning-fast and your users incredibly happy. So, buckle up, grab a virtual coffee, and let's get cracking!
What Exactly is This "Critical Rendering Path" Thing Anyway?

Imagine you're building a LEGO castle. You can't just throw all the bricks together randomly. You need a plan, a sequence. First, you lay the foundation. Then, you build the walls, followed by the towers, and finally, you add the decorative flags. The Critical Rendering Path is the web browser's equivalent of this LEGO plan.
In technical terms, the Critical Rendering Path refers to the sequence of steps a web browser takes from the moment it receives HTML and CSS to the point where it can visually render pixels on the screen. It's the chain of events that must happen for your user to see your beautiful website.
Let's break down these steps:
Parsing HTML: The browser receives the HTML document and starts parsing it, creating a Document Object Model (DOM). The DOM is like a tree-like structure representing the content and hierarchy of your HTML.
Processing CSS: As the browser encounters CSS in your HTML (either inline, in <style> tags, or linked external stylesheets), it parses this CSS and creates a CSS Object Model (CSSOM). The CSSOM represents the styles applied to your DOM elements.
Combining DOM and CSSOM into a Render Tree: This is where the magic starts to happen. The browser combines the DOM and CSSOM to create a Render Tree. The Render Tree contains only the visible elements of your page and their associated styles. Elements like <head> or elements with display: none; are excluded.
Layout (or Reflow): With the Render Tree in hand, the browser needs to figure out the exact position and size of each element on the screen. This is the layout or reflow process. It's like measuring and marking where each LEGO brick goes.
Painting (or Rasterization): Finally, the browser takes the layout information and "paints" the pixels onto the screen. This is the painting or rasterization step, where your website finally comes to life visually.
Crucially, the CRP is "critical" because any delay in these steps will directly impact the perceived loading speed of your page. If one step is slow, the entire process is held up.
Why Should You Even Care About the CRP? (The "Advantages" Section, aka "Why You Need This Speed!)

Optimizing the Critical Rendering Path isn't just an exercise for web developers to show off their technical prowess. It has tangible, real-world benefits for your website and your business.
Blazing-Fast User Experience: This is the most obvious and impactful advantage. Users get to see content sooner. This leads to less frustration, more engagement, and a higher likelihood of them sticking around. Imagine landing on a site and seeing content appear within seconds rather than staring at a blank screen. That's the power of CRP optimization.
Improved Conversion Rates: When users can quickly see and interact with your product or service, they are more likely to convert – whether that's making a purchase, signing up for a newsletter, or filling out a form. Speed directly translates to revenue.
SEO Boost: Search engines like Google absolutely love fast websites. A good Core Web Vitals score, heavily influenced by CRP performance, is a significant ranking factor. A faster site can mean higher search engine rankings, leading to more organic traffic.
Reduced Bounce Rates: If your site takes too long to load, users will likely hit the "back" button and try a competitor. Optimizing the CRP helps keep users on your site longer.
Mobile-First Performance: With the majority of internet traffic coming from mobile devices, optimizing for speed on these networks is paramount. CRP optimization is especially critical for mobile users who often have slower connections.

The Flip Side of the Coin: Potential "Disadvantages" (Or, "Why It's Not Always a Walk in the Park")

While the benefits are undeniable, optimizing the CRP isn't always a straightforward process. There are challenges and considerations to keep in mind.
Complexity and Learning Curve: Understanding the intricacies of the CRP and implementing effective optimizations can be challenging. It requires a good grasp of web technologies and how browsers work.
Balancing Performance with Functionality: Sometimes, aggressive optimization might involve trade-offs. For instance, deferring non-critical JavaScript might mean certain interactive elements appear slightly later. Finding the right balance is key.
Requires Ongoing Maintenance: The web is constantly evolving, and new content or features can impact your CRP. It's not a "set it and forget it" kind of optimization. Regular monitoring and adjustments are necessary.
Potential for Over-Optimization: While rare, it's possible to get so caught up in optimizing that you might accidentally break something or make your code less readable and maintainable.
Tooling and Debugging: Identifying and fixing CRP bottlenecks can sometimes involve complex debugging and the use of specialized performance tools.

Key "Features" of a Well-Optimized Critical Rendering Path (The "How-To" Section)

Now that we understand what the CRP is and why it matters, let's get to the good stuff: how to actually optimize it! This is where we get hands-on with some actionable strategies.
1. Minimize the Critical HTML & CSS

The core idea here is to reduce the amount of data the browser has to process for the initial render.
Inline Critical CSS: This is a game-changer. Instead of waiting for an external CSS file to download, you embed the CSS required to render the above-the-fold content directly within your HTML. This allows the browser to start rendering immediately.
Example:
<!DOCTYPE html>
<html>
<head>
<title>My Speedy Page</title>
<style>
/* Inline critical CSS for above-the-fold content */
body {
font-family: sans-serif;
margin: 0;
}
.hero-section {
background-color: #f0f0f0;
padding: 50px;
text-align: center;
}
h1 {
color: #333;
}
</style>

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>
<body>
<section class="hero-section">
<h1>Welcome to My Fast Website!</h1>
<p>Content that loads instantly.</p>
</section>

</body>
</html>
Explanation:
The <style> block contains the CSS needed for the .hero-section to be visible immediately.
The link rel="preload" with as="style" tells the browser to fetch the styles.css file but not to block rendering. onload then applies it once downloaded.
The noscript tag ensures that users with JavaScript disabled still get the stylesheet.

Minify HTML and CSS: Remove unnecessary characters (whitespace, comments) from your HTML and CSS files. This reduces file sizes, leading to faster downloads. Many build tools (like Webpack or Gulp) and online minifiers can do this automatically.

2. Defer and Asynchronously Load JavaScript

JavaScript can be a major bottleneck in the CRP. When the browser encounters a <script> tag, it typically stops parsing HTML, downloads the script, executes it, and then resumes parsing. This is often unnecessary for scripts that aren't immediately needed for rendering.
defer Attribute: This attribute tells the browser to download the script in the background while continuing to parse HTML. The script will then execute only after the HTML parsing is complete.
Example:
<script defer src="my-non-critical-script.js"></script>
async Attribute: This attribute also downloads the script in the background, but it executes the script as soon as it's downloaded, potentially before HTML parsing is complete. This is useful for independent scripts that don't rely on the DOM.
Example:
<script async src="my-analytics-script.js"></script>
Move Scripts to the End of <body>: While defer and async are preferred, a common older technique is to place all your non-critical JavaScript just before the closing </body> tag.
Code Splitting: Break down your JavaScript into smaller chunks. Load only the JavaScript that's necessary for the current view or interaction. Tools like Webpack excel at this.

3. Optimize Images

Images are often the largest assets on a webpage and can significantly impact loading times.
Optimize Image Files: Compress your images without sacrificing visual quality. Use tools like TinyPNG, ImageOptim, or even online compressors.
Use Modern Image Formats: Consider using formats like WebP, which offer better compression and quality compared to JPEG or PNG.
Responsive Images: Use the <picture> element or srcset attribute to serve appropriately sized images for different screen sizes and resolutions.
Example:
<picture>
<source srcset="large-image.webp" media="(min-width: 1024px)">
<source srcset="medium-image.webp" media="(min-width: 600px)">
<img src="small-image.webp" alt="A descriptive alt text">
</picture>
Lazy Loading: Defer the loading of images that are not immediately visible on the screen (i.e., below the fold). They will only load when the user scrolls down.
Example:
<img src="your-image.jpg" loading="lazy" alt="Descriptive alt text">

4. Leverage Browser Caching

Caching allows the browser to store copies of your website's resources (HTML, CSS, JavaScript, images) locally. This way, on subsequent visits, the browser can load these resources from the local cache instead of re-downloading them from the server, dramatically speeding up loading times.
Set Appropriate Cache Headers: Configure your web server (e.g., Apache, Nginx) to send Cache-Control headers for static assets.
Example (Nginx configuration):
location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|webp)$ {
expires 1y;
add_header Cache-Control "public, no-transform";
}

5. Prioritize Above-the-Fold Content

The "above-the-fold" content is what users see immediately when they land on your page without scrolling. This is the most critical part to get right for a good initial impression.
Identify Critical Resources: Determine which HTML, CSS, and JavaScript are absolutely essential to render this initial viewport.
Inline Critical CSS: As mentioned earlier, this is key for visual content.
Defer Non-Critical JavaScript: Move or defer scripts that aren't needed for the immediate display of above-the-fold content.

6. Reduce Server Response Time

Even with optimized front-end assets, a slow server can still cripple your CRP.
Optimize Server-Side Code: Ensure your backend code is efficient and doesn't take too long to generate the HTML response.
Use a Content Delivery Network (CDN): CDNs distribute your website's assets across multiple servers globally. This means users can download assets from a server geographically closer to them, reducing latency.
Enable HTTP/2 or HTTP/3: These newer protocols offer significant performance improvements over HTTP/1.1, especially for handling multiple requests concurrently.

7. Eliminate Render-Blocking Resources

Any resource that prevents the browser from rendering the page until it's downloaded and processed is considered "render-blocking."
Identify Render-Blocking CSS and JavaScript: Use browser developer tools (Performance tab) to identify these bottlenecks.
Inline Critical CSS: The primary solution for render-blocking CSS.
Defer/Async JavaScript: The primary solution for render-blocking JavaScript.

Tools for the Job (Your Performance Toolkit)

To effectively optimize your CRP, you'll need the right tools:
Browser Developer Tools: Your best friend! Chrome DevTools, Firefox Developer Edition, and Edge DevTools offer invaluable features:
Performance Tab: Record page loads to analyze the CRP, identify bottlenecks, and see how long each step takes.
Network Tab: Inspect all network requests, their sizes, and timings.
Lighthouse: An automated tool built into Chrome DevTools that audits performance, accessibility, SEO, and more. It provides actionable recommendations for CRP optimization.

WebPageTest: An online tool that allows you to test your website's speed from various locations and browsers.
GTmetrix: Another popular online tool for analyzing website speed and performance.
Google PageSpeed Insights: Provides a score for your page's performance on both mobile and desktop, with specific recommendations.

Conclusion: Embrace the Speed!

The Critical Rendering Path is a fundamental concept for anyone serious about website performance. By understanding how browsers construct your webpages and by strategically optimizing the resources that contribute to the initial render, you can unlock a world of benefits: happier users, higher conversions, and better search engine rankings.
It's not about magic tricks; it's about a systematic approach to delivering your content efficiently. Start by identifying your current CRP bottlenecks, then implement the strategies discussed – inline critical CSS, defer JavaScript, optimize images, leverage caching, and prioritize above-the-fold content.
Remember, website performance is an ongoing journey, not a destination. The web is dynamic, and your optimizations will need to adapt. But by making the Critical Rendering Path a core part of your development process, you'll be well on your way to building faster, more engaging, and ultimately, more successful websites. So, go forth and optimize – your users (and your bottom line) will thank you for it!#frontend #performance #webdev #software #coding #development #engineering #inclusive #community
Optimization: Critical Rendering Path
#community #software #webdev #coding #development #engineering
Dev Community @[email protected]
2026-10-27
You open the repo on your first morning, the README says "run the app, ask it something," and forty seconds later an answer appears on the phone. Nobody on the team can tell you whether that text came from the bundled on-device model, from a remote endpoint someone configured last quarter, or from a fixture left in a debug build. That uncertainty is not a small onboarding annoyance, because every later measurement you record inherits it.
This post is a first-hour exercise for a junior engineer joining a mobile AI repo. The goal is not to ship a feature, and it is not to improve latency or accuracy; the goal is to make provenance visible, so that when you do open your first PR you already know which execution path you exercised. Everything below is a proposed harness that you run on your own device, not a report of numbers I measured on yours.
Why provenance belongs in hour one

In a normal backend repo you can read the config and know which database answered. In a mobile AI repo the same request can be served by three different things depending on build type, network state, and whether an asset survived the packaging step. If you skip this check, you will eventually write a careful benchmark, show it to your reviewer, and discover the phone was calling a cached response the whole time.
The exercise below gives you three things you can rely on for the rest of onboarding: a build that fails loudly when the model asset is missing, a debug banner that names the source of the last response, and a repeatable way to exercise the remote path on purpose.
The three sources to distinguish

Bundled asset. A model file inside the app package, loaded from local storage with no network involved.
Remote endpoint. An HTTP call to a server the app was pointed at, which may be a shared development host or something you started yourself.
Fixture or cache. A stubbed response in debug builds, or a stored answer replayed from a previous run.
Your banner only needs to name which of these produced the last result. It does not need to be pretty, and it should not ship in release builds.
Step 1: make a missing model asset a build failure

Before you touch any inference code, prove that the file you think is packaged actually is. Add a verification task to the app module and wire it into the check lifecycle. Substitute your own asset name and the checksum your team stores alongside the artifact.
// app/build.gradle.kts (proposed harness)
val modelDir = layout.projectDirectory.dir("src/main/assets/models")
// Placeholder on purpose: copy the real digest from your artifact record.
val expectedDigests = mapOf(
"classifier-small.tflite" to "<sha256-from-your-artifact-record>"
)
tasks.register("verifyModelAssets") {
val dir = modelDir
inputs.dir(dir)
doLast {
expectedDigests.forEach { (name, want) ->
val file = dir.file(name).asFile
require(file.exists()) { "Missing model asset: $name" }
val got = java.security.MessageDigest.getInstance("SHA-256")
.digest(file.readBytes())
.joinToString("") { "%02x".format(it) }
require(got == want) { "Checksum mismatch for $name\nexpected=$want\n got=$got" }
}
println("verifyModelAssets: OK")
}
}
tasks.named("preBuild") { dependsOn("verifyModelAssets") }
Expected observation on a healthy checkout is a single verifyModelAssets: OK line before compilation. Then deliberately rename the asset once, run ./gradlew :app:assembleDebug, and confirm the build stops with the message you wrote. If it compiles anyway, your app has a runtime download path you have not found yet, and that is the most important thing you will learn all day.
Step 2: print the source of the last response

A tiny recorder next to your inference entry point costs almost nothing and removes the guessing. Keep it debug-only, and never log prompt text or user content in it.
// Proposed harness. Field names follow your app's existing types.
sealed interface ModelSource {
data class Bundled(val asset: String, val digestPrefix: String) : ModelSource
data class Remote(val host: String, val path: String) : ModelSource
data class Fixture(val name: String) : ModelSource
}
object Provenance {
private val seen = ArrayDeque<ModelSource>()
fun record(source: ModelSource) {
seen.addLast(source)
if (seen.size > 20) seen.removeFirst()
if (BuildConfig.DEBUG) Log.d("Provenance", describe(source))
}
fun last(): ModelSource? = seen.lastOrNull()
private fun describe(s: ModelSource): String = when (s) {
is ModelSource.Bundled -> "bundled ${s.asset} sha256:${s.digestPrefix}"
is ModelSource.Remote -> "remote ${s.host}${s.path}"
is ModelSource.Fixture -> "fixture ${s.name}"
}
}
Call Provenance.record(...) exactly where the response is produced, not where the request is built, because a retry can change the answer's origin. If you use Compose, a two-line debug overlay reading Provenance.last() is enough; on iOS the same idea maps to a #if DEBUG view or an os_log line.
What the banner buys you

You can tell a reviewer which path your PR screenshot came from.
You can catch a silent fallback before it becomes a "works on my machine" thread.
You can reproduce a bug by forcing the source rather than hoping.

Step 3: exercise the remote path deliberately

Many teams use a hosted endpoint for early integration work, and some projects offer free model access plus a free server option so a new contributor can get a working call without a billing conversation. The open-source project MonkeyCode is one of these, and its operator describes a free model-access tier and a free server option for trying the workflow; the same operator-supplied description puts the free allowance at 10 million tokens. Treat that figure as a starting point, not a contract, and re-read the project's current terms before you plan any budget around it.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
The useful part for onboarding is narrower than the marketing: a shared free endpoint lets you prove that your client's request shape, timeout, and error handling work before you depend on a host only three people can reach. Time the first call rather than trusting it.
# Shape only. Use the base URL and path from the project's own setup docs.
BASE_URL="https://<your-endpoint-from-the-project-docs>"
for i in 1 2 3; do
curl -sS -o /dev/null \
-w "attempt=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
-H "Content-Type: application/json" \
-d '{"prompt":"ping","max_tokens":8}' \
"$BASE_URL/v1/complete"
done
Record three numbers per attempt and note whether the first one is slower than the rest, which would suggest a cold path rather than a steady one. Do not run a load test against shared free infrastructure; three sequential calls teach you what a first-hour contributor needs, and concurrency experiments belong on a host your team controls.
When the banner disagrees with your mental model
SymptomLikely broken pathFirst checkBuild passes with the asset deletedSilent download or remote fallbackGrep for the model URL in build configBanner says remote in airplane modeCached response or fixtureClear app storage, rerunBanner says bundled but answers varyPrompt template changedDiff template file against mainFirst remote call takes much longerCold endpoint or cold radioRepeat three times, note radio stateWorks after reinstall onlyAsset copied at first launchInspect first-run copy logic

Each row is a rollback condition, not a curiosity. If your banner reports remote while the device has no network, you have found something worth raising before you write feature code.
Evidence to record before your first PR

Fill this in on your own hardware and paste it into the PR description or your onboarding notes. Reviewers trust a filled table far more than a sentence claiming it works.
Device model and OS version, plus whether it is a physical device or a simulator.
Framework and dependency versions, including the inference runtime and build tool versions.
Build type used for the observation, and the exact command you ran.
Network state during each step, including radio type and whether airplane mode was toggled.
Permission state for any sensor the feature reads, and whether you revoked it mid-run.
Power conditions, such as plugged in versus battery, and any low-power mode.
Which provenance value the banner printed for each observation.

Limitations and who should skip this

This harness assumes your app can load a model from local storage. If your product is server-only inference, a bundled-asset check adds noise and you should stop after step 2 and document the endpoint instead. Teams with a managed model registry may already enforce digests in CI, in which case duplicating the check locally is waste. Checksumming a multi-hundred-megabyte asset on every build slows feedback loops noticeably, so scope the task to debug variants or run it on a schedule.
Finally, the banner is diagnostic tooling. It must be stripped or gated in release builds, because hostnames and asset digests are information you gain nothing from publishing.
If you run this in your own repo, I would like to see the environment rather than the conclusion: device, OS, framework versions, the transition steps you used, and whether the banner recovered, restarted, or silently disappeared. If you want a place to start the remote path without provisioning a host first, the project's free tier and free server option are the shortest route to a first honest measurement.#ai #mobile #android #testing #software #coding #development #engineering #inclusive #community
Know Which Model Answered: A First-Hour Provenance Banner for Mobile AI Repos
#ai #mobile #community #software #coding #android
Dev Community @[email protected]
2026-10-27
The review usually opens with a demo that looks fine. An agent plans four edits, applies them to a workspace on a remote box, and reports success; the tests are green and everyone relaxes. Two hours later a human's refactor is gone, and nobody can point at the request that removed it. Is that a model problem, a server problem, or a protocol problem?
I think it is a protocol problem almost every time, and I want to make the case with an executable fixture rather than an architecture diagram. Below is the event order I keep reconstructing in reviews, the invariant it violates, and a small simulator that will fail your design for you. Everything here is a model of a system, not a benchmark of a vendor.
1. The event order that silently wins

A planner reads the workspace at revision 0 and emits three steps against app.py. Step 1 applies and the workspace moves to revision 1. While step 2 is in flight, either a human edits that file or the session is re-routed to a different model that re-plans the remainder; both are ordinary events, not incidents.
Step 2 still carries the content hash it was planned against. If the executor applies patches by path without checking that hash or the revision, the write lands on content the planner never saw, and the old bytes vanish. Nobody gets an error, because a patch is not a request — it is a claim about a state that may already be false.
The failure is invisible precisely when it is most expensive. The agent's summary says "updated handler and tests", the test run passes because the overwritten hunk was unrelated, and the loss only surfaces at the next merge. Who is supposed to notice that?
2. The invariant, stated once

No step may be applied unless the state it was planned against is still the state it is applied to, or the step has been explicitly rebased onto the new state.
That is it. Note what the invariant does not say: it does not say a step is correct, and it does not say a retried step is safe. A revision fence prevents stale acceptance; idempotency prevents double application. Teams routinely build one, assume they have the other, and then argue about whose bug it is.
3. Declared assumptions

One writer per file at a time; concurrent multi-writer edits are out of scope and need a merge protocol, not a fence.
The workspace has a monotonic revision counter and a per-file content hash that are both persisted with the workspace itself.
A step is planned from a readable snapshot and carries (step_id, base_rev, path, pre_hash, patch).
Execution may be preempted at any point between "patch written" and "client received the result".
Model identity may change inside a session, because routing, fallback, or a free-tier allowance running out can move you to another model without warning.

4. Data flow and failure domains

There are three state holders and they fail independently: the planner's context (lossy, model-dependent), the executor's workspace (authoritative, preemptible), and the client's view of progress (optimistic, retried). The only durable truth is the workspace plus whatever journal you persist alongside it.
Failure domains worth separating in review: stale plan (planner state diverged), lost ack (executor applied, client did not learn), duplicate delivery (client retried an applied step), and re-plan drift (a new model emits steps against an old base). They need different mechanisms, and a single retry counter hides all four.
5. The fixture

This is deterministic Python with no model calls, so the verdicts below are properties of the protocol, not of any provider.
# fence_sim.py - deterministic, no LLM involved
from dataclasses import dataclass
@dataclass(frozen=True)
class Step:
step_id: str
base_rev: int
path: str
pre_hash: str
patch: str
class Workspace:
def __init__(self):
self.rev = 0
self.files = {"app.py": "v0"}
self.journal = set() # persisted with the workspace
def hash(self, path):
return self.files
[path] def write(self, path, content):
self.files[path] = content
self.rev += 1
class Executor:
"""fence: 'none' | 'plan' | 'step'; dedupe: journal-backed idempotency"""
def __init__(self, ws, fence="step", dedupe=True):
self.ws, self.fence, self.dedupe = ws, fence, dedupe
self.plan_rev = None
def plan(self, rev):
self.plan_rev = rev
def stamp(self, s):
if self.fence == "step":
return Step(s.step_id, self.ws.rev, s.path, self.ws.hash(s.path), s.patch)
if self.fence == "plan":
return Step(s.step_id, self.plan_rev, s.path, s.pre_hash, s.patch)
return s
def exec(self, s):
s = self.stamp(s)
key = (s.step_id, s.base_rev)
if self.dedupe and key in self.ws.journal:
return "deduped"
if self.fence != "none":
if s.base_rev != self.ws.rev:
return "rejected:stale_rev"
if self.ws.hash(s.path) != s.pre_hash:
return "rejected:pre_hash"
self.ws.write(s.path, s.patch)
if self.dedupe:
self.ws.journal.add(key)
return "applied"
Two lines deserve attention. The journal lives in Workspace, not in the executor, because an in-process dedupe set dies with the server that was preempted — which is exactly the trap. And stamp is where fence granularity is decided, so you can argue about it in one place.
6. Injecting the three failures

Run the same three scenarios across fence modes and record the verdicts. The interference classes are injected explicitly, so the denominator is the number of injections, not the number of suspicious log lines.
def scenario_concurrent_edit(fence):
ws = Workspace(); ex = Executor(ws, fence=fence); ex.plan(ws.rev)
s1 = Step("s1", 0, "app.py", "v0", "v1")
s2 = Step("s2", 1, "app.py", "v1", "v2")
assert ex.exec(s1) == "applied"
ws.write("app.py", "human-refactor") # interference: rev 2
return ex.exec(s2)
def scenario_preemption_retry(fence):
ws = Workspace(); ex = Executor(ws, fence=fence)
s1 = Step("s1", 0, "app.py", "v0", "v1")
ex.exec(s1)
# ack lost; client replays s1 against a fresh executor, same persisted workspace
return Executor(ws, fence=fence).exec(s1)
def scenario_replan_drift(fence):
ws = Workspace(); ex = Executor(ws, fence=fence); ex.plan(ws.rev)
ex.exec(Step("s1", 0, "app.py", "v0", "v1"))
ex.plan(ws.rev) # new model re-plans from rev 1
return ex.exec(Step("s2", 0, "app.py", "v0", "v1-tail"))
Expected output, because the simulation is deterministic and calls no model:
fence=none concurrent_edit -> applied preemption_retry -> applied twice replan_drift -> applied
fence=plan concurrent_edit -> rejected:stale_rev preemption_retry -> rejected:stale_rev replan_drift -> rejected:stale_rev
fence=step concurrent_edit -> rejected:stale_rev preemption_retry -> rejected:stale_rev replan_drift -> applied
dedupe on concurrent_edit -> rejected:stale_rev preemption_retry -> deduped replan_drift -> applied
Read the second and third rows together, because that is the argument. A plan-level fence turns every retry into a spurious rejection and every legitimate re-plan into a dead end; it is loud, but it is loud in the wrong places. A step-level fence plus a persisted journal gets you the two properties you actually want, and it costs you a durable set of (step_id, base_rev) keys.
7. Making it a property, not a demo

Three scenarios are an anecdote. Turn them into invariants and let a random interleaving search hunt for violations — this is the part I would block a design review on.
def invariants_hold(ws, results):
# P1: every applied step saw base_rev == rev at apply time
assert all(r.rev_at_apply == r.base_rev for r in results if r.status == "applied")
# P2: journal is append-only per (step_id, base_rev)
assert ws.journal == set(ws.journal)
# P3: no path content was replaced by a step older than the current rev
assert all(r.base_rev <= r.rev_at_apply for r in results)
Then fuzz: shuffle {human_edit, preempt, retry, replan, duplicate_delivery} over a fixed step list, run 5,000 seeds, and assert P1 and P2 for every seed with fences on. Run the same search with fence="none" to extract a minimal counterexample, and put that event order in the PR description as the regression case. A protocol claim without a counterexample search is a preference.
8. Where the free tier changes the arithmetic

If your executor is a shared, preemptible environment and your planner can move between models at any time, then re-plan drift and lost acks are not edge cases — they are the steady state. That is the actual architectural consequence of running agents on free resources, and it argues for cheap, persisted fences rather than expensive coordination.
I use MonkeyCode as the concrete instance of that environment in this review: it is an open-source coding agent whose operator supplies free model access (currently advertised as a 10M-token allowance) and a free server option. Treat those numbers as operator-supplied and re-verify them on the project page before you design around them, because allowances and routing change faster than any architecture does. My interest here is narrow: a free server makes preemption ordinary, and free model access makes mid-session re-routing ordinary, so both of my injected interferences become Tuesday.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
9. Tradeoffs I would write down
MechanismBuys youCosts youFails whenNo fenceThroughput, simplicitySilent lost updatesAny concurrent editPlan-level fenceLoud, cheap rejectionRe-planning whole plans, spurious retriesModel swap or long plansStep-level fencePrecise staleness detectionA re-stamp on every dispatchSemantic overlap between stepsPersisted journalIdempotent retry across preemptionDurable key storage, growth controlJournal not persisted atomically with the writeCheckpoint per stepFast compensationStorage, restore latencyLarge binaries, long test suites
10. Verdicts: reject, replay, or compensate
Event orderCorrect verdictWhyStep arrives, base_rev < current rev, no overlapReject, re-plan from current revThe plan is stale; the patch is not recoverableStep arrives, journal contains (step_id, base_rev)Replay the stored resultThe work is done; the ack is what was lostStep applied, tests for touched files failCompensate to the checkpointFence passed, semantics did notNew model re-plans mid-session from current revAccept if re-stamped and preconditions holdDrift is expected, staleness is notTwo steps with overlapping hunks in one planReject the plan at admissionA fence cannot order siblings
11. What I would change next

Persist the revision counter, file hashes, and journal in one atomic write, so a crash cannot leave a patch without its key.
Stamp base_rev at dispatch, never at plan time, and log both values — the delta is your drift signal.
Bound the journal by session and drop it only after a checkpoint the workspace itself can prove.
Run the fuzz job in CI with fences on, and store the minimal counterexample from fence="none" as a named regression seed.
Add a sibling-overlap check at plan admission, because per-step fences order nothing within a plan.

12. Limits, and who should skip this

The fixture models file-level hashing and a single writer; it says nothing about merge semantics, and it does not evaluate whether a patch was any good. If your model swap also changes plan quality, this protocol will happily accept a worse plan that happens to be revision-correct. That is a separate evaluation problem, and no fence will solve it for you.
Skip this if your agent is single-turn and single-file with a human watching every apply, if your platform already gives each step an atomic worktree or VM snapshot, or if you cannot persist a journal durably — half of this mechanism without the journal is worse than none, because it rejects retries without making them safe.
So here is the question I would leave in the review thread: which event order in your system breaks the invariant — a human edit racing step two, an ack lost after the write, or a re-plan against a stale base — and for that specific order, should the executor reject, replay, or compensate?#ai #architecture #distributed #testing #software #coding #development #engineering #inclusive #community
Treat a Coding-Agent Step as a Revision-Fenced Command, Not a Prompt
#ai #community #software #coding #architecture #development
Dev Community @[email protected]
2026-10-27
Quick Answer

A fleet tracking backend should treat every GPS ping as untrusted input. Sort pings by device time, drop duplicates and impossible values, reject poor fixes and teleport jumps, hold position while a vehicle is parked, and add hysteresis to geofences. Keep the raw stream, store the cleaned stream beside it, and snap to roads only after cleaning. The Python below was tested on synthetic data only, not on live device feeds.
Why does a fleet app receive bad GPS data?

Some of the reasons are written down in vendor documentation. Samsara's vehicle locations documentation says a device reports about every 5 seconds while the vehicle is on and about once an hour while it is off. It also says identical consecutive records can occur, and that GPS interference in a garage can suppress updates even when the vehicle shows as on. The same page says the device keeps a rolling 30 days of location data, so after a connection is restored the buffered points become available through the API.
Read together, those statements describe four problems a backend must expect: duplicate rows, silent gaps, a misleading "on" status, and late data that arrives out of order. This is one vendor's documentation. Other vendors will behave differently, so read the equivalent page for the device you actually use.
What should the ingest layer check before it stores a ping?

My suggestion (author judgement, not a standard) is six cheap checks, run in this order:
Sort by device timestamp, so late arrivals land in the right place.
Drop exact duplicates (same time and position).
Reject impossible values, including out-of-range coordinates and the 0,0 position that some receivers report before they have a fix.
Reject poor fixes, where the reported accuracy is worse than a threshold.
Reject teleport jumps, where the implied speed between two kept points is not plausible for a vehicle.
Hold position while parked, so receiver jitter does not draw a wandering trail.
The thresholds in the code (50 m accuracy, 45 m/s, 10 m jitter) are starting values I chose for the example. Tune them against your own vehicles and devices.
from dataclasses import dataclass
from math import radians, sin, cos, asin, sqrt
@dataclass(frozen=True)
class Ping:
device: str
ts: int # epoch seconds, device clock
lat: float
lon: float
acc_m: float = 10 # reported horizontal accuracy in metres
def haversine_m(a, b):
r = 6371000.0
p1, p2 = radians(a.lat), radians(b.lat)
dp, dl = p2 - p1, radians(b.lon - a.lon)
h = sin(dp / 2) ** 2 + cos(p1) * cos(p2) * sin(dl / 2) ** 2
return 2 * r * asin(sqrt(h))
def clean(pings, max_acc_m=50, max_speed_ms=45, jitter_m=10):
"""Return a cleaned, time-ordered list for ONE device."""
seen, ordered = set(),
[] for p in sorted(pings, key=lambda p: p.ts): # 1. fix ordering
key = (p.ts, round(p.lat, 6), round(p.lon, 6))
if key in seen: # 2. drop duplicates
continue
seen.add(key)
if not (-90 <= p.lat <= 90 and -180 <= p.lon <= 180): # 3. impossible values
continue
if p.lat == 0 and p.lon == 0: # "null island" fix
continue
if p.acc_m > max_acc_m: # 4. poor fix
continue
ordered.append(p)
out =
[] for p in ordered:
if out:
prev, dt = out[-1], p.ts - out[-1].ts
if dt <= 0:
continue
d = haversine_m(prev, p)
if d / dt > max_speed_ms: # 5. teleport jump
continue
if d < max(jitter_m, p.acc_m): # 6. parked jitter
p = Ping(p.device, p.ts, prev.lat, prev.lon, p.acc_m)
out.append(p)
return out
Testing status: I ran six unit tests with Python 3.13 on synthetic points: out-of-order input, duplicates, 0,0 and poor-accuracy points, a teleport jump, parked jitter, and geofence flapping. All six passed. I have not run this against real device feeds, so treat it as a teaching sample and not production code.
How do you stop geofence alerts from flapping?

A vehicle parked near the edge of a depot boundary can cross it back and forth because of receiver noise, and each crossing can fire an alert. Two techniques help. Use hysteresis, which means the vehicle enters a zone inside radius r but only exits beyond r plus a buffer. Then require several consecutive pings before the state changes.
class Geofence:
"""Circle fence with hysteresis: enter inside r, exit only outside r + buffer."""
def __init__(self, lat, lon, r_m, buffer_m=30, confirm=2):
self.c = Ping("fence", 0, lat, lon)
self.r, self.buf, self.confirm = r_m, buffer_m, confirm
self.inside, self._streak = False, 0
def update(self, p):
d = haversine_m(self.c, p)
want_inside = d <= self.r if not self.inside else d <= self.r + self.buf
if want_inside == self.inside:
self._streak = 0
return None
self._streak += 1
if self._streak >= self.confirm:
self.inside, self._streak = want_inside, 0
return "enter" if self.inside else "exit"
return None
In the test, a sequence of distances of 150, 90, 95, 110, 98, 105, 160 and 170 metres from a 100 m fence produced exactly one enter event and one exit event. Two of those readings (110 m and 105 m) were outside the 100 m radius while the vehicle was still inside the zone, and the buffer absorbed both.
Should you snap points to roads?

Map matching can clean what the filters above leave behind, but it has its own rules. Google's Roads API documentation says one snap-to-roads request accepts up to 100 GPS points and returns points snapped to the most likely road. It recommends keeping consecutive points at or below about 300 metres apart, and offers an optional interpolate setting that adds points following the road shape. Interpolated points have no original index, so the response can contain more points than the request.
OSRM's Match service takes optional timestamps, which must increase, and optional per-point radiuses that default to 5 metres. The documentation suggests using the device's reported accuracy. It returns null for points dropped as outliers and a confidence score from 0 to 1 for each matching. The OSRM page I read was for version 5.5.1, so check the documentation for the version you run.
My judgement: snap after cleaning, keep the raw point and the snapped point side by side, and treat a low confidence score as a flag for review rather than an error.
How do you find vehicles near a depot quickly?

PostGIS documents ST_DWithin as a cheap filter that can use a spatial index, while ST_Distance computes exact distances and cannot use indexes. For geography values the distance is in metres. The common pattern is to filter with ST_DWithin first and sort with ST_Distance on what remains.
SELECT v.id, ST_Distance(v.last_position, d.location) AS metres
FROM vehicles v
JOIN depots d ON d.id = 7
WHERE ST_DWithin(v.last_position, d.location, 2000)
ORDER BY metres;
This query is untested. It assumes both columns are geography with a spatial index on last_position, so check the types and the index in your own schema.
What should the fleet database store?

In my view three tables cover most needs: an append-only table of raw pings, a table of cleaned pings that maps and reports read, and a small table holding the last known position per vehicle for proximity queries. Keeping the raw data lets you re-run a better filter later and settle disputes about a route.
Which are the top five fleet management app development companies?

Teams that prefer to buy this work instead of building it can compare the five partners below. The list is not a ranking of quality.
Figures below come from each company's own website and are self-reported, so confirm them directly before signing anything.
1. Dev Technosys

Dev Technosys is a fleet management app development company with 250+ professionals that does business globally. Its fleet page describes connecting GPS tracking, fuel monitoring and dispatching systems, then automating assignments, maintenance alerts and journey updates. The company builds its own platforms and connects them to existing business systems through APIs instead of configuring third-party ERP products. It states an 89% project success rate and says most new business comes through client referrals; both claims are self-reported. That scope fits teams that already own tracking hardware and need workflow software around it.
2. N-iX

N-iX lists fleet management software development as a dedicated service. Its page covers telematics and predictive-maintenance integration, ELD and IoT sensor integration, hours-of-service compliance modules, route-planning and dispatch engines, and mobile fleet apps. A case study describes a GPS-tracked in-vehicle Linux gateway, a Google Cloud IoT platform and an Android driver app for a telematics client, in a partnership that began in February 2021. The site states over 2,400 software engineers, and the case study gives no fleet outcome figures. N-iX suits teams that need hardware-to-cloud telematics work from one vendor.
3. Intellias

Two fleet case studies sit on the Intellias site. In the first, a Florida telematics client has worked with the company since 2018 on a platform with real-time GPS mapping, idle-time tracking and diagnostic trouble code reporting, and the page says it handles 100,000+ vehicles with data points every 30 seconds. The second is a native iOS, Android and Angular truck-tracking front end for a large car maker, tested on 1,000 vehicles and offered in more than 20 countries. Intellias suits teams that expect high vehicle counts and need a backend built for that volume.
4. Altoros

Altoros says it was founded in 2001 and lists GPS tracking software for car rental, trucking and delivery, fleet management with vehicle tracking and dispatch, and IoT platforms for fleets. Its logistics page cites a transport management case serving 100+ companies and processing 10,000+ automated orders a day, with operator workload cut by up to 70%, plus a truck-parking app prototype covering 10,000+ locations. All of these figures are self-reported, and the page names no ISO certification, so ask for evidence. Altoros suits teams that want an IoT-heavy build from a long-established vendor.
5. STX Next

Describing itself as a Python-native team with more than 20 years of experience, STX Next lists fleet management systems, route optimization, electronic proof of delivery, predictive maintenance and IoT integration on its transport and logistics page. Named case studies include Sendcloud (a carrier integration proof of concept), GS1 Polska (a location-data app for drivers) and T Dispatch (dispatch software). The page mentions Python, IoT, RFID, AWS, Azure and Snowflake and lists delivery centers in Poznan and Merida, but it states no headcount. STX Next suits teams that prefer a Python backend.
FAQ

How often should a fleet device send a position?
Samsara's documentation describes about every 5 seconds while a vehicle is on and about hourly while it is off. Your hardware and data plan set the real figure.
Should raw pings be deleted after cleaning?
In my view, no. Keep them for a retention period your own policy allows, so you can re-run improved filters later.
Do I need map matching in every fleet app?
No. Many dashboards work with cleaned points. Matching helps most when you report distance driven on roads.
What accuracy threshold should I use?
The example uses 50 m as a starting value. Tune it per vehicle type and device.
Can I use this code in production?
It is a teaching sample tested on synthetic data. Add tests built from real device samples first.#python #backend #iot #architecture #software #coding #development #engineering #inclusive #community
Designing a Fleet Tracking Backend That Handles Bad GPS Data
#community #software #iot #coding #python #architecture
Dev Community @[email protected]
2026-10-27
AI can generate a financial model that looks coherent, contains valid formulas, and produces a plausible result while still being wrong in ways that matter.
A formula can reference the wrong cell. A cost assumption can be expressed in the wrong unit. A revenue schedule can omit a phase. A model can calculate correctly from an unsupported market assumption.
These are different failure modes, and they need different controls. For real estate feasibility models, the objective should not be to ask whether an AI-generated workbook looks correct. It should be to establish which properties can be tested automatically, which assumptions require evidence, and which decisions must remain with a qualified human reviewer.
A useful validation architecture has five layers:
Structural validation
Deterministic calculation checks
Domain and consistency checks
Evidence and provenance checks
Human review and approval
No single layer is sufficient.
1. Separate the output from the evidence

Consider a hypothetical development model with the following inputs:
Site area and developable area
Permitted gross floor area
Unit mix or lettable area
Revenue assumptions
Construction and other development costs
Financing assumptions
Development programme
Exit assumptions
The model calculates development costs, revenue, cash flows, residual land value (RLV), and potentially internal rate of return (IRR).
For example, a model might calculate an RLV of £4 million. That output can be mathematically consistent with the workbook and still be commercially misleading if the revenue assumptions are unsupported or the construction cost basis is outdated. Validation therefore needs to test both the calculation and the justification for its inputs.
2. Layer one: validate the structure before the numbers

Before reviewing financial logic, validate the shape of the generated output. If an AI system is expected to return structured data before creating a workbook, define an explicit contract. JSON Schema is one established option for specifying required fields, data types, and constraints.
See the JSON Schema getting-started guide.
A simplified model input contract might look like this:
{
"project_id": "DEMO-001",
"currency": "GBP",
"site_area_sqm": 5000,
"gross_floor_area_sqm": 12000,
"construction_cost_per_sqm": 1800
}
This is illustrative data, not a market benchmark or a recommendation for a production schema.
A structural validator could check that:
Required fields are present.
Numeric values are actually numeric.
Areas and costs use declared units.
Currency is explicitly identified.
Values fall within defined technical bounds.
Unexpected fields are rejected or handled deliberately.
Missing values are not silently replaced with zero.
The last point is important. Zero and unknown are not equivalent. If a finance rate is missing, substituting zero can make a model appear more profitable. A missing value should normally trigger a validation error or an explicit unresolved status.
Structural validation establishes that the model can be interpreted. It does not establish that the model is economically sensible.
3. Layer two: use deterministic checks for deterministic rules

Rules that can be expressed precisely should not depend on an LLM's judgment. For example, if a model defines construction cost as gross floor area multiplied by construction cost per square metre, the expected calculation is:
\text{GFA}
\times
\text{Cost per sqm}
]
For the hypothetical inputs above:
[
12{,}000 \times £1{,}800 = £21{,}600{,}000
]
A deterministic test can independently calculate the expected result and compare it with the workbook output.
from decimal import Decimal
gfa_sqm = Decimal("12000")
cost_per_sqm = Decimal("1800")
reported_cost = Decimal("21600000")
expected_cost = gfa_sqm * cost_per_sqm
assert expected_cost == reported_cost
This test checks arithmetic for the stated formula. It does not establish that the GFA is permitted, that the cost rate is appropriate, or that the formula captures every relevant cost.
A production implementation should also define tolerances where appropriate, particularly when comparing rounded spreadsheet values or calculations involving floating-point numbers.
Other deterministic checks might include:
Revenue equals the sum of its components.
Total costs reconcile to their component schedules.
Cash flow totals reconcile across periods.
Unit counts and areas reconcile between schedules.
The reported output matches an independently calculated result.
A sensitivity case actually changes the intended input.
Required formula cells are not unexpectedly blank or replaced by constants.
Where possible, use independent calculations rather than simply checking that a formula cell contains a formula. A formula can exist and still be wrong.
4. Layer three: validate model relationships

Many serious errors are not syntax errors or arithmetic errors. They are inconsistencies between parts of the model.
Suppose a development model contains:
120 residential units in the unit schedule
116 units in the sales schedule
Revenue calculated using the sales schedule
Construction costs calculated using the unit schedule
Every formula may evaluate successfully, but the workbook contains a discrepancy that needs resolution.
Domain-level checks can flag conditions such as:
Unit counts that differ across schedules.
Areas that exceed a declared model constraint.
Revenue periods that do not align with the programme.
Cost totals that exclude a populated cost category.
An exit value that uses an inconsistent timing assumption.
A sensitivity scenario that changes revenue but leaves dependent calculations unchanged.
An IRR calculation using a cash-flow range that omits a period.
These checks should be encoded as explicit rules wherever the intended relationship is known.
Some rules require context. For example, whether a particular cost should be included in a development budget depends on the model's scope and conventions. A validator should not impose a universal rule where none exists.
Instead, it should identify the relevant condition, record the rule being applied, and send ambiguous cases for review.
5. Layer four: validate the provenance of assumptions

A financial model can pass every arithmetic test and still fail as an analytical tool.
The reason is straightforward: calculations cannot establish the truth of their inputs.
For every material assumption, a validation system should try to preserve:
The value and unit.
The source or origin of the value.
The source's date and relevant data period.
The geography and asset type, where applicable.
The transformation from source evidence to model assumption.
Any manual adjustment made by the analyst.
The model locations that depend on the assumption.
Consider a construction cost assumption of £1,800 per square metre. A validator might confirm that the figure is numeric, the unit is recorded, and the workbook uses it consistently. Those checks do not establish whether the figure is suitable for the location, asset type, specification, and cost period. That question requires appropriate evidence and professional interpretation.
An LLM may help extract candidate assumptions from documents or explain how a value is used in a workbook. The extracted result should still be checked against its source, and the resulting assumption should remain distinguishable from the underlying evidence.
A useful principle is:
Traceability makes an assumption inspectable. It does not make the assumption correct.
6. Layer five: make human review a defined state transition

Human review should not be an informal final glance after an automated process has already treated the model as complete.
A practical workflow can represent validation explicitly:
GENERATED
|
v
STRUCTURE_CHECKED
|
v
CALCULATIONS_CHECKED
|
v
DOMAIN_CHECKED
|
v
EVIDENCE_REVIEWED
|
v
HUMAN_APPROVAL_REQUIRED
|
+----> APPROVED FOR THE DEFINED PURPOSE
|
+----> RETURNED FOR CORRECTION
|
+----> BLOCKED: UNRESOLVED ISSUE
The states are illustrative, but the distinction matters. A successful automated test should not automatically mean that a model is approved. Approval should be scoped to a defined version of the workbook, its assumptions, its evidence, and its intended use.
A reviewer should be able to see:
What was generated.
Which automated checks passed.
Which checks failed or were skipped.
Which assumptions lack adequate evidence.
What changed after a correction.
Who approved the model and for what purpose.
If a material input or formula changes after approval, the system should identify which checks need to run again and whether the earlier approval remains valid. This is where versioning and change tracking become part of model governance rather than administrative overhead.
7. Design the exception path before the success path

Validation is often designed around a clean example: the model is generated, every check passes, and the user receives the output. Production systems need to handle less convenient outcomes.
A failed check should produce actionable information. “Validation failed” is less useful than “The unit count in the sales schedule differs from the unit schedule; review the linked inputs before approving revenue.”
Similarly, a warning should not disappear simply because a later stage of the workflow succeeds. For auditability, preserve the check identifier, the model version, the result, the relevant evidence, and the resolution.
8. Measure validation quality without inventing an accuracy score

A single “model accuracy” percentage can hide important distinctions. A workbook might pass every arithmetic test while containing several unsupported assumptions. Another may contain a harmless formatting issue but have fully reconciled calculations and well-documented inputs.
A more useful validation report separates categories:
Structural checks passed or failed.
Deterministic calculation checks passed or failed.
Domain checks passed, failed, or were not applicable.
Assumptions with verified, missing, or conflicting evidence.
Open exceptions and their severity.
Human review status.
The scope and version of the approved output.
If the system is evaluated over time, track false negatives and false positives for individual validation rules against a reviewed test set. Record the test cases, expected outcomes, rule versions, and known limitations.
Do not interpret a high pass rate as proof that the model is correct. It may simply mean that the checks cover only a narrow set of failure modes.
The purpose of validation is to make known risks visible and testable, not to manufacture certainty.
9. A practical implementation sequence

A team introducing validation around AI-generated financial models does not need to automate every review step at once.
A sensible sequence is:
Define the contract. Specify the required inputs, output fields, units, and missing-value behaviour.
Write deterministic tests. Start with totals, reconciliations, formula ranges, and independent calculations.
Add domain checks. Encode known cross-schedule relationships and clearly defined constraints.
Track provenance. Associate material assumptions with sources, dates, units, and transformations.
Introduce exception handling. Make failures explicit and prevent unresolved material issues from being silently treated as passed.
Define human approval. Record the reviewer, workbook version, purpose, and outstanding qualifications.
Build a regression suite. Retain representative valid and invalid examples and rerun the checks when the generation logic or validation rules change.
The test suite should include deliberate failures, not only successful examples. Examples might include missing finance assumptions, inconsistent unit counts, a formula referencing the wrong period, and a source whose geography does not match the project.
This helps test whether the validation process detects the intended problem rather than merely accepting a plausible-looking output.
Conclusion

Human-in-the-loop validation is not a person checking an AI result after the important work is finished. It is a system design in which deterministic rules handle deterministic questions, domain checks expose inconsistencies, evidence is kept separate from assumptions, and a human reviewer remains accountable for unresolved judgments.
For financial modelling, that distinction is material. A workbook can be well-formed without being economically sound, mathematically consistent without being supported by market evidence, and ready for review without being ready for a decision.
The objective is not to make every AI-generated model look trustworthy. It is to make the model's logic, assumptions, limitations, and unresolved issues sufficiently visible that a professional can challenge it before relying on the result.#feasibility #realestate #ai #financial #software #coding #development #engineering #inclusive #community
Human-in-the-Loop Validation for AI-Generated Financial Models
#ai #community #software #coding #development #engineering
Dev Community @[email protected]
2026-10-27
Most deployment advice starts with architecture. Draw the boxes, pick the services, ship it. I believed that was the whole job until a client project showed me otherwise.
Two projects can have the same architecture diagram and still need very different deployments. What decides it is the features of the app and the shape of its traffic. This post is about the project that made that clear to me, and how I ended up on EC2 with Ansible instead of the more fashionable options.
The client

I took over a project and moved it onto EC2 first. The brief was short: keep it secure, and don't let it fall over when traffic jumps.
Traffic was not large, about 3K users a day. What made it interesting was how it moved:
WhenTrafficWhat it meantNormal dayAbout 3K usersTwo modest servers are enoughProduct releases/eventsDouble or more, in burstsExtra capacity for a few hours, not all yearDecember holidaysA different pattern againDon't pay for peak capacity every month

The important detail is that I knew these dates in advance. Fixed servers would have been either oversized all year or too small on release day.
Which setup for which situation

Before the details, here is the short version. Find the row closest to your project.
Your project looks likeGo forTrade-offSteady traffic, small team, spikes on known datesEC2 + Auto Scaling + ALBCheapest at steady load, but you patch the serversSudden, unpredictable spikesECS on FargateNothing to patch, but a higher price per unitSmall event-driven jobs (resize an image, send an email)LambdaPay only when it runs, but 15 minute limit and DB connection pressureWebSockets or long-lived connectionsFargate or EC2Connections stay open, a poor fit for LambdaHeavy 24/7 loadECS on EC2 + Savings PlansBest price at constant load, but two layers to scaleA team already living in KubernetesEKSReuses existing skills, big operational cost

ECS and Fargate are sometimes presented as rivals. They are not: ECS is the orchestrator, and Fargate is one way for ECS to run your containers.
The app has to be ready first

Before anyone touches a server, a few things must be true in the code. I have seen more "infrastructure problems" caused by these than by AWS itself.
The app is stateless. If sessions or files live on one machine's disk, you cannot run two copies. Sessions go in JWT or Redis, uploads go to S3.
There is a /health endpoint. The load balancer and Auto Scaling both rely on it to decide whether an instance is alive.
I know my database connection limit. Every new instance brings its own connection pool. Ten instances with a pool of 20 is 200 connections, and the database may not allow that.
Cron jobs run in one place. Otherwise they fire on every copy of the API at the same time.
None of this is infrastructure work. It is plain application code, and it decides what you can do afterwards.
The options, judged for this client
OptionIn its favourAgainst itFor this clientEC2 + Auto Scaling + ALBCheapest at steady load, full control, my Ansible roles work as they areI patch the OS, new instances take minutes to boot, I tune the scalingMy pickECS on FargateNothing to patch, scales per taskRoughly 15 to 40% more per unit than raw EC2, no host access, no GPURight if nobody wants to own serversLambdaNear-zero cost when idle, instant scaling15 minute limit, DB connection pressure, awkward for WebSocketsSide jobs onlyEKSHuge ecosystemSteep learning curve and running costOverkill

I chose EC2 with Auto Scaling for three reasons. The traffic is small, I know the spike dates, and I already had Ansible roles that configure the servers. Scheduled scaling covers the known spikes without paying a Fargate premium all year. If nobody on the team wanted to own patching, I would flip that decision and use Fargate without a second thought.
Autoscaling: what scales on what

This is the part where being a developer helped most, because several of the real problems live in the app and not in AWS.
Minimum capacity. Two instances across two availability zones. If one dies, the site stays up.
The scaling rule. I use target tracking, either CPU around 60% or ALB requests per target. Requests per target follows actual traffic, so there are no thresholds to guess.
Known events. A scheduled action raises the minimum before a release or before December. A new instance takes minutes to become useful, so waiting for the spike to start is already too late.
Boot time. I bake an AMI after the Ansible role runs. New servers start ready instead of installing everything at boot.
Health checks. Use the ELB health check type, pointed at /health, so a broken instance is replaced automatically.
The database. Compare the maximum connections against instances multiplied by pool size. This is the most common surprise when a Node app scales out.
One Node-specific trap is worth knowing. Node runs on a single core per process. On a 2-vCPU instance running one Node process, CPU may never go much past 50%, so a CPU-based rule never fires. Run one process per core (PM2 cluster mode works) or scale on requests per target instead.
Before any release day, load test staging with k6 or Artillery. It tells you more than any estimate.
Security: EC2 versus Fargate
ConcernEC2FargateOS patchingMeAWSSSH accessI have to lock it downNone (ECS Exec if you need a shell)IsolationI manage the shared hostEach task is isolatedIAMInstance roleTask role per serviceHost-level security agentsPossibleNot possible

If compliance requires an agent on the host, that points to EC2. Otherwise Fargate gives you a smaller attack surface for less work.
On EC2 my Ansible hardening role covers the basics: key-only SSH with root login disabled and no public SSH (Session Manager or a locked-down IP), servers and database in private subnets with security groups chained from ALB to app to DB, secrets kept in Ansible Vault or Secrets Manager and never in the repo, and automated RDS backups together with a restore I have actually tested.
Ansible and Terraform: who does what

I work with Ansible, and this setup lives in it.
Roles configure the servers: packages, users, SSH hardening, nginx, Docker.
A playbook deploys a new version one server at a time, with a health check between each.
Ansible Vault holds the deploy-time secrets.
A dynamic inventory (aws_ec2) finds the instances that Auto Scaling created, by tag. Instances come and go, so a hard-coded host list breaks quickly.
The same roles bake the AMI.
Before changing anything, I preview it:
ansible-playbook -i inventory/prod.aws_ec2.yml site.yml --check --diff
And this is a trimmed version of the deploy playbook:
- hosts: web
become: true
serial: 1 # one server at a time, the ALB keeps traffic on healthy ones
vars_files:
- secrets.yml # encrypted with ansible-vault
tasks:
- name: Run the new version of the API
community.docker.docker_container:
name: api
image: "{{ app_image }}:{{ app_version }}"
state: started
recreate: true
restart_policy: always
published_ports: ["3000:3000"]
env:
DB_HOST: "{{ db_host }}"
DB_PASSWORD: "{{ db_password }}"
- name: Wait until /health answers
ansible.builtin.uri:
url: http://localhost:3000/health
status_code: 200
register: health
retries: 10
delay: 3
until: health.status == 200
I don't use Terraform on this project, but it is worth saying where it fits. It is strong at creating and tracking cloud resources such as the VPC, ALB, RDS and IAM, with state you can review. A team that rebuilds environments often may prefer it for that layer and keep Ansible for what runs inside the servers. The two are not rivals.
When I would choose differently

If nobody wants to patch servers, or traffic becomes unpredictable, I would move to Fargate.
If the load turns into a heavy 24/7 one, I would look at ECS on EC2 with Savings Plans.
If the team grows into Kubernetes, EKS starts to make sense.
For small side tasks like image resizing or emails, I would add Lambda next to the main app.

What I took from it

The server was never the real decision. The traffic shape, the app being ready to scale, and a setup I can repeat with one command were. Pick the simplest option that survives your busiest day, keep it in code, and load test it before that day arrives.
If you have deployed for a client with spiky traffic, I would like to hear what you chose and what you would change.#aws #node #ansible #webdev #software #coding #development #engineering #inclusive #community
Same Architecture, Different Deployment: Why Traffic Shape Beats Diagrams
#community #software #webdev #coding #development #aws
Dev Community @[email protected]
2026-10-27

One of the interesting things about using a chatbot is how naturally a conversation can continue.
I can ask a question, provide additional information, refer to something mentioned earlier, and expect the assistant to understand what I mean.
But while studying how chatbots work, I learned an important distinction:
A continuous conversation is something the application must create. It is not automatically provided by every individual LLM call.
What happens when I send a follow-up message?

Imagine this conversation:
User: My food hasn't arrived.
Assistant: Would you like to wait or request a refund?
User: I want a refund.
The last message makes sense because of the earlier exchange.
But what happens if the application sends only “I want a refund” to the model?
The model may not have the information needed to understand the situation. The application needs to preserve the relevant conversation history and include it in the next request.
This was my first important takeaway: the application is responsible for maintaining the conversation.
Memory is not necessarily inside the model

Suppose I tell a chatbot that my preferred programming language is Java.
Later, I ask which language I prefer.
It might seem that the model has permanently learned something about me.
However, the application could have stored that preference, retrieved it when needed, and supplied it as context for the new request.
The process could look like this:
User Information
↓
Application Memory
↓
Retrieve Relevant Information
↓
Add to Current Context
↓
LLM Generates Response
This is different from training the model and updating its learned parameters.
That distinction changed how I think about chatbot memory. The user experience may look like persistent memory even when the application is retrieving stored information and passing it to the model.
More context is not always better

Another concept that stood out to me was the context window.
A model can process only a limited amount of information in a given interaction.
An application might store hundreds or thousands of messages, but it does not necessarily need to send every message with every request.
It can select recent messages, summarize older exchanges, or retrieve only information relevant to the current question.
Why does this matter?
Because repeatedly including a growing conversation can increase input token usage, which can affect cost and latency. It also consumes some of the model's available context capacity.
The important design question is not simply:
“How much context can I send?”
It is:
“Which information does the model actually need to answer this request well?”
Streaming is a user-experience decision

The lecture also connected next-token generation to streaming.
Instead of waiting for an entire answer before showing anything, an application can display generated content progressively as it arrives.
This can make an application feel more responsive, although it does not necessarily make the underlying model generate the complete response faster.
It is another reminder that the experience users see depends on application design, not just model capabilities.
And then there is hallucination

A model can generate an answer that sounds convincing without the answer being factually correct.
Fluent language and verified information are two different things.
For a real application, this matters enormously.
Imagine a support chatbot answering questions about an order. It should retrieve the actual order status rather than inventing one. If an action requires authorization, the application must enforce that authorization instead of trusting a prompt alone.
Depending on the use case, retrieval, external APIs, tool calling, validation, guardrails, and evaluation can improve reliability.
They reduce certain risks, but they do not guarantee that every answer will be correct.
What I'm taking away as a software engineer

I'm beginning to see chatbot engineering as more than sending prompts to a model.
The application needs to manage conversation history, select context, retrieve relevant information, control access to tools, and handle responses appropriately.
These are familiar software engineering concerns applied to a new kind of capability.
My biggest takeaway from this lecture is:
A good chatbot does not merely generate responses. Its application must provide the right context and manage those responses responsibly.
As I continue studying Forward Deployed Engineering and Generative AI, I want to understand not only how models work, but also how to build reliable applications around them.#ai #llm #softwareengineering #software #coding #development #engineering #inclusive #community
How Does a Chatbot Remember? The Engineering Behind Context and Memory

#ai #community #software #coding #development #engineering
Charmys Army, the Comic Strip @[email protected]
2026-10-27

Charmy’s Army in “DEE SEAST – The Hell of the Ball” – Part 3: Blue Vests and Brown Bananas
<<< Previous COMIC strip NEXT COMIC STRIP >>>
In the third installment of our saga, panic reaches a fever pitch before colliding directly with mundane retail logistics. Convinced that Walmart’s customer service desk has instituted a terrifying new policy for processing refunds, the ponytail girl spiraled into sheer dread: will returning a defective toaster get her tossed into a holding pen to be devoured by domesticated ghouls? Thankfully, the blonde clears the air. Dee isn’t eating dissatisfied shoppers; she works in the meat department devouring the expired cuts. She isn’t a mindless trash can, either—as corporate HR would insist, she is a proud “Waste Management Facilitator.”
The fluorescent lights of the retail district buzzed overhead like a hive of mechanical hornets. The ponytail girl stood dead in the center of the sidewalk, completely frozen in terror, clutching both hands to her face. Her eyes were practically the size of saucers, and her breathing sounded like a bellows working overtime.
“I bought a set of non-stick sauté pans three weeks ago,” she whispered, her voice trembling with sheer, unadulterated existential dread. “The coating is already flaking off near the handle. I have the receipt in my purse. I was literally planning to go to Customer Care this afternoon. But now? Now I know the truth! They’re going to look at my receipt, see that the packaging is torn, hit a discreet red button under the desk, and drop me down a trapdoor into Dee’s feeding pit!”
The blonde stared at her friend for three long seconds, an expression of profound exhaustion settling across her features. She pinched the bridge of her nose and let out a deep, shuddering sigh that blew a stray blonde lock out of her eyes.
“Have you ever, in your entire life, heard of a big-box store feeding actual human customers to an employee?” the blonde asked flatly. “Do you realize the liability insurance premiums on that alone? The Occupational Safety and Health Administration would have field inspectors crawling through the air ducts within forty-eight hours. The paperwork would take decades.”
“Corporations do terrible things to protect their quarterly profit margins!” the ponytail girl insisted, gesticulating wildly toward the towering blue sign visible above the tree line. “Think about it! Customer returns cost money! Salvage freight costs money! If you replace the return desk with an apex predator from beyond the grave, refund requests drop to absolute zero overnight! It’s the ultimate cost-cutting measure!”
“She’s in the meat department, you absolute lunatic,” the blonde barked, grabbing her friend by the arm and dragging her along the pavement. “She doesn’t eat dissatisfied patrons who lost their receipt for a shower curtain. She eats the brown ground chuck and the discount chicken thighs that have been sitting in the display cooler forty-eight hours past their sell-by date!”
The ponytail girl blinked once. Twice. Her frantic breathing slowed down, though the look of absolute disgust remained firmly plastered across her face. “Wait… what?”
“You heard Charmy earlier,” the blonde continued, shaking her head. “Food waste is one of the biggest logistical hurdles in supermarket management. Stores throw away literal tons of spoiled produce, dented cans, and graying beef every single calendar year. Landfills charge dumping fees. Commercial composters have strict guidelines. But an undead post-human? Their digestive systems—or whatever remaining chemical soup passes for an internal organ—can neutralize bacteria that would put a vulture into an intensive care unit.”
“So she’s a garbage disposal,” the ponytail girl summarized, wrinkling her nose until her freckles scrunched into a tight knot. “A glorified, walking, rotting kitchen sink drain with bangs.”
“Charmy said she prefers the title Waste Management Facilitator,” the blonde corrected with an ironic smirk. “Corporate America doesn’t hire monsters; they hire operational specialists. They probably gave her an orientation badge, a five-minute video on slips, trips, and falls, and a designated break room in the refrigerated storage annex so she doesn’t scare the bakery associates.”
Across the street, Charmy and Dee had paused outside a small convenience store. Dee was leaning against a lamppost, her head tilted at a precarious angle that suggested her neck vertebrae were merely suggestive guidelines. A passing delivery driver glanced at her, double-took, and quickly crossed the street with an expression of profound confusion, but nobody screamed. Nobody dialed the national guard. The world had simply absorbed the unthinkable and filed it away under routine municipal oddities.
“I don’t know what’s worse,” the ponytail girl muttered, watching Dee attempt to scratch her shoulder and nearly dislocating her collarbone in the process. “The idea that the zombie apocalypse ended with our society almost being overrun, or the idea that it ended with the survivors realizing zombies could be exploited for unpaid sanitation labor.”
“Welcome to late-stage capitalism,” the blonde replied with a dry chuckle. “If a catastrophic virus wipes out twenty percent of the population, the remaining eighty percent won’t mourn; they’ll just figure out how to put the fallen to work clearing out the dairy aisle. But hey, look at the bright side: at least Dee is earning an honest living. It’s more than half the guys you’ve dated this year can say.”
“That is a low blow and completely uncalled for,” the ponytail girl grumbled, though she couldn’t suppress a faint, cynical grin. “At least my exes showered once a week. Dee looks like she just crawled out of an abandoned septic tank behind a haunted waterpark.”
“True,” the blonde agreed, watching as Charmy gently handed Dee a small bottle of hand sanitizer, which she promptly attempted to drink before Charmy calmly redirected it to her palms. “She’s definitely rough around the edges. But that brings up an even more pressing dilemma: with Halloween coming up, what does an integrated undead citizen do for social life? And more importantly… what does this mean for the town dance?”
TO BE CONTINUED….

Rate this:
#books #fantasy #fiction #shortStory #writing

#books #fantasy #fiction #shortstory #writing
Dev Community @[email protected]
2026-10-27
Halfway through a two-day batch run I noticed that one answer looked suspiciously like the answer to the item two rows above it, and I could not prove which input it came from. Has that ever happened to you — the job finished, the output looked plausible, and you had no way to defend a single row of it? These are my field notes from fixing that, with the harness I ended up keeping.
What I was actually trying to do

I had a flat list of short, independent text items, and I wanted one short answer per item, written to a ledger I could re-run safely. Sending one request per item is the obvious path, but it doubles the number of round trips, and every round trip is another chance to miss a wall-clock deadline. So I tried the cheaper-looking option: put two items in one prompt and ask for two answers back. Note that this is not a quota argument — I never measured a quota, and I am not claiming one exists. The motivation was purely fewer round trips and fewer half-finished batches.
For context, the driver ran on MonkeyCode's free server option, and the calls went through its free model access. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I will keep the product out of the technical claims, because the failure below is a property of my prompt and my validator, not of any provider.
Day one: the harness I wrote

The whole thing is one file with no dependencies beyond the Python standard library, which was deliberate. If the harness can move between machines with scp and nothing else, I can debug it anywhere, including on a machine I do not own. Here is the shape of it.
# batch_harness.py — stdlib only; you supply call_model()
import hashlib
import json
from dataclasses import dataclass, field
def item_id(text: str) -> str:
return hashlib.sha256(text.strip().encode("utf-8")).hexdigest()[:12]
@dataclass
class Item:
text: str
id: str = field(init=False)
def __post_init__(self):
self.id = item_id(self.text)
def build_prompt(items):
blocks = "\n".join(f'<item id="{i.id}">{i.text}</item>' for i in items)
return (
"Answer each item separately. Return a JSON array only, no prose.\n"
'Each element must be {"id": "<id from the item tag>", "answer": "<answer>"}.\n'
"Copy ids exactly. Do not renumber, merge, or reorder the items.\n\n"
+ blocks
)
The important line is the id, and it is deliberately boring: a hash of the input text, truncated. Same input, same id, forever — so a second run of the same ledger is a no-op by construction. If the id were derived from the model's output, a reworded answer would look like a brand-new item, and the queue would quietly grow.
The validator, which is where the actual work lives

def validate(items, raw):
try:
payload = json.loads(raw)
except json.JSONDecodeError as exc:
return None, f"not_json: {exc.msg}"
if not isinstance(payload, list):
return None, "not_a_list"
rows = [r for r in payload if isinstance(r, dict)]
got = [str(r.get("id", "")).strip().lower() for r in rows]
want = [i.id for i in items]
if len(got) != len(set(got)):
return None, "duplicate_ids"
if set(got) != set(want):
missing = sorted(set(want) - set(got))
extra = sorted(set(got) - set(want))
return None, f"set_mismatch missing={missing} extra={extra}"
answers = {r["id"].strip().lower(): r.get("answer", "") for r in rows}
if any(not isinstance(a, str) or not a.strip() for a in answers.values()):
return None, "empty_answer"
return answers, "ok"
Two details I will defend. First, I lowercase and strip the id before comparing, because that transform is lossless — an uppercase hex string identifies exactly one item. Second, I refuse every lossy match: no positional mapping, no prefix matching, no edit distance. Fuzzy matching is precisely how you end up with two answers for one item and a warm feeling that everything is fine.
What broke on day two

Two failure modes showed up, and both were invisible to a try/except around the HTTP call.
Answers came back without ids. The response was a clean JSON array of {"answer": ...} objects, in a plausible order. Nothing errored. A positional mapper would have accepted this and been right — probably.
Ids came back that I never sent. One batch returned eleven-character ids instead of twelve; another returned ids that were valid hex but belonged to nothing in my prompt. Set equality caught both instantly; a length check would not have.
Why is partial acceptance worse than a loud failure here? Because a batch that is 50% valid does not stop the run — it just moves two items into the wrong bucket, and you discover it when someone reads the output.
The fix: fail the batch, then fall back to one

def run_batch(items, call_model, attempts=2):
for attempt in range(1, attempts + 1):
raw = call_model(build_prompt(items))
answers, verdict = validate(items, raw)
if verdict == "ok":
return answers, {"attempts": attempt, "verdict": verdict, "fallback": False}
out = {}
for item in items:
raw = call_model(build_prompt([item]))
answers, verdict = validate([item], raw)
out[item.id] = answers[item.id] if verdict == "ok" else None
return out, {"verdict": "fallback_single", "fallback": True}
python batch_harness.py --input items.jsonl --batch-size 2 --ledger runs/ledger.jsonl
tail -n 3 runs/ledger.jsonl
{"batch": ["9f2c41ab07de", "41ab9f2c07de"], "attempt": 1, "verdict": "set_mismatch", "extra": ["7d10c3a1f0b2"], "fallback": true, "model_string": "<record what you actually got>"}
The ledger excerpt above is illustrative — the values are placeholders, and the deliverable is the columns, not the numbers. Record the model string you actually received, because free access is not the same thing as a pinned version, and a drifting model is a variable you want in the log.
The run sheet I would keep
ColumnWhy it earns its placebatch (sorted ids)Reproducing a failure needs the exact inputs, not the item countattemptTells you whether retries are rare or structuralverdictDistinguishes not_json from set_mismatch, which are different bugsextra / missingThe invented ids are the signal that the prompt driftedfallbackA rising fallback rate means the batch size is too aggressive

And a decision table for batch size, which is really a question about failure cost:
Items per callUse it whenDo not use it when1Items are long, or ordering is contractualYou are already comfortable with the fallback path2Items are short, independent, and id-stableOne bad item can poison its neighbour4+You have eyes on the ledger during the runYou cannot inspect the first hundred rows by hand
What I would repeat, and what I would not

I would repeat the input-derived id and the strict set-equality check on day one, not day two; both are ten lines and they replace a whole class of late-night doubt. I would repeat keeping every model call behind one function, because it made the fallback trivial to write. I would not repeat starting at batch size two before watching a hundred single-item calls go through cleanly. The boring baseline is what tells you whether batching is safe for your particular items.
Who should not do this

Anyone whose items reference each other, since batching changes what the model can see at once.
Anyone under a hard latency or availability guarantee, because a free endpoint is a shared one and I make no promises about it.
Anyone who cannot hand-inspect the first hundred outputs, since the validator checks shape and nothing else.
Anyone paying per token on a long shared instruction, where duplicating it per item costs more than the round trips you save.
The harness does not know whether an answer is correct — it only knows that every id it sent came back once. That is a smaller promise than it sounds, and it is the one I can actually keep. If you run this drill on the free model access, start at batch size one and let the ledger tell you when two is safe.#python #ai #testing #debugging #software #coding #development #engineering #inclusive #community
48-Hour Field Notes: I Batched Two Items Per Call and Lost Track of Which Answer Belonged to Which Input
#ai #community #software #coding #python #development
Psychology News Robot @[email protected]
2026-10-26

DATE: October 26, 2026 at 04:00PM
SOURCE: PSYPOST.ORG
** Research quality varies widely from fantastic to small exploratory studies. Please check research methods when conclusions are very important to you. **
-------------------------------------------------
TITLE: Women reach orgasm more often alone, but partnered orgasms are more closely tied to sexual satisfaction
URL: https://www.psypost.org/women-reach-orgasm-more-often-alone-but-partnered-orgasms-are-more-closely-tied-to-sexual-satisfaction/
Women tend to reach orgasm more often during solo sex than with a partner, but a new study suggests that partnered orgasms are the ones more closely tied to overall sexual satisfaction. The survey of nearly 28,000 users of a period-tracking app, published in Archives of Sexual Behavior, also found that a wider variety of partnered activities was linked to greater satisfaction, while variety in solo sex showed no such benefit.
Sexual satisfaction refers to a person’s overall evaluation of how fulfilling and pleasurable their sex life is, a measure closely tied to overall health and quality of life. Past research has consistently linked women’s sexual satisfaction to how often they reach orgasm and to sexual variety, which is the number of different sexual behaviors a person engages in. For instance, a 2017 national survey of U.S. adults found that people in long-term relationships who incorporated a wider range of intimate behaviors and had more frequent orgasms tended to feel more satisfied with their sex lives.
Reaching orgasm with a partner, however, is far less consistent for women than reaching orgasm alone, a disparity examined in a 2024 review of the partnered orgasm gap. That review noted that 38 to 92 percent of women usually or always climax when masturbating, and that women’s orgasm rates rise sharply when sexual activity includes direct stimulation of the clitoris, a small, highly sensitive organ at the top of the vulva. During partnered sex with men, routines often center on vaginal penetration alone, leaving many women without the stimulation needed to climax.
Because solo sex is such a reliable source of orgasms, one might expect frequent masturbation to boost sexual satisfaction, yet prior research has yielded mixed results. Among studies of women in a 2024 systematic review, 40 percent found no link between masturbation and sexual satisfaction, a third found a negative link, and about a quarter found a positive one.
The review’s authors argued that negative links may arise when masturbation compensates for unfulfilling or absent partnered sex, but they found that for women, masturbation more often seemed to complement partnered sex rather than replace it. The context of solo activity may also matter: a study covered by PsyPost in 2020 indicated that women who used vibrators both alone and with a partner reported higher sexual satisfaction than those who used vibrators only alone.
Most earlier studies examined only a narrow set of partnered behaviors or treated masturbation as a single category without comparing specific solo and partnered activities side by side. To explore how distinct behaviors, variety, and orgasms relate to satisfaction across both contexts, Yella Hewings-Martin and Adam C. Cunningham of Flo Health UK Limited and their colleagues surveyed users of the Flo health app to test whether solo orgasms and variety relate to overall satisfaction the same way partnered ones do.
The researchers recruited participants between April 11 and May 5, 2024, via in-app messages shown to adult English-speaking Flo users. From 70,424 initial responses, the team excluded users who did not complete the survey, lacked a valid app ID, or failed two attention-check questions, leaving 27,931 participants with an average age of 28 years. Nearly all respondents were biologically female (98.9 percent) and identified as women (96.4 percent); 70.7 percent identified as heterosexual, 23.1 percent as bisexual or pansexual, and 81.3 percent had a male partner.
Respondents reported on their sex lives over the previous six months, rating their overall sexual satisfaction on a five-point scale and their orgasm frequency from never to almost always. They also rated how often they engaged in 13 partnered and 13 solo sexual activities, including vaginal penetration, clitoral stimulation by hand or vibrator, watching erotica, and role-play, and how often each behavior led to orgasm. Multiplying activity frequency by orgasm frequency yielded weighted orgasm scores for solo and partnered contexts. Those who climaxed more often in one setting than the other selected up to three reasons from 22 options to explain why.
Across the full sample, 56.2 percent of participants were moderately or very satisfied with their overall sex life, while 19.5 percent were moderately or very dissatisfied. Roughly 36.9 percent reached orgasm almost always or always, and 22.9 percent did so most of the time, whereas 20.6 percent climaxed less than half the time or never. Overall orgasm frequency had a moderate positive correlation with sexual satisfaction (r = 0.38, on a scale where 1 would be a perfect match): 61.2 percent of very satisfied respondents reached orgasm almost always, though 19.5 percent of very dissatisfied respondents also climaxed almost every time.
The data showed a difference between the behaviors performed most consistently at every encounter and those practiced by the widest share of women overall. Vaginal penetration without other stimulation was the partnered behavior most consistently performed every time (39.7 percent), but clitoral stimulation by a partner’s hand, mouth, or tongue was the most widespread partnered activity overall (90.2 percent at least sometimes), followed closely by vaginal penetration paired with other body stimulation (90.1 percent) and by vaginal penetration paired with clitoral touch (90.0 percent).
The authors noted that clitoral stimulation topping the list of widespread partnered behaviors contrasts with older surveys where vaginal intercourse was most common. They suggest this likely reflects their more detailed questions about a six-month period, though they also speculate that it could partly reflect a younger sample (38 percent of respondents were aged 18 to 25).
In solo sex, clitoral stimulation by hand was both the most widespread behavior (84.6 percent) and the most consistent (44.5 percent every time), while only 5.5 percent practiced solo vaginal penetration alone every time. Across all 13 paired comparisons of similar activities, women reached orgasm more frequently when alone than with a partner, with differences ranging from small to moderate. Overall, 47 percent of participants reported reaching orgasm more often during solo sex, compared to 21 percent with a partner and 27 percent who reported no difference.
In solo sessions, clitoral stimulation with a vibrator or dildo, watching erotica, and clitoral stimulation by hand were linked to the highest orgasm rates. During partnered sex, the highest orgasm rates came from using sex toys together, combining vaginal penetration with clitoral stimulation, and masturbating with a partner present, while vaginal penetration alone and anal stimulation were linked to the lowest rates in both contexts.
Participants’ own explanations pointed to both psychological and physical factors. Women who climaxed more often alone most commonly cited inadequate stimulation from a partner, an absence of pressure to perform, reduced body image self-consciousness, and feeling safer to let go because they controlled the stimulation. Many also pointed to partnered obstacles such as a partner finishing too soon, difficulty communicating preferences, life stress, or painful intercourse. By contrast, those who reached orgasm more often with a partner emphasized emotional intimacy, adequate partner stimulation, and heightened arousal from attraction to their partner.
To examine how solo and partnered experiences predicted overall sexual satisfaction, the authors analyzed the 19,469 respondents who had engaged in partnered sex during the past six months. Partnered orgasm frequency was the strongest positive predictor of sexual satisfaction, whereas solo orgasm frequency showed a tiny negative association in initial models and was not statistically significant in the final model. Participants averaged 7.79 of the 13 partnered activities and 6.45 of the 13 solo activities; greater partnered variety predicted higher satisfaction, while greater solo variety was weakly associated with lower satisfaction. Together, these factors accounted for about 16 percent of the differences in satisfaction between participants.
In a separate model of 20,805 partnered-sex participants controlling for relationship status, being in a relationship and engaging in greater partnered variety both predicted higher overall orgasm frequency, whereas solo variety was not statistically significant. That model accounted for about 7 percent of the differences in orgasm frequency between participants.
The positive tie between partnered climax and satisfaction aligns with research covered by PsyPost in 2018, which examined heterosexual newlywed couples rather than a broad sample of female app users and similarly found that a woman’s partnered orgasm frequency is positively linked to her sexual satisfaction. At the same time, the findings on solo sex and variety stand in tension with a study covered by PsyPost in 2022, which linked frequent masturbation in women to higher sexual satisfaction alongside frequent intercourse and variety. That earlier study, however, looked at overall masturbation frequency across a broad adult population, whereas the new study specifically evaluated solo orgasm frequency and sexual variety among female app users.
There are a few things to keep in mind when interpreting these findings. Because the survey captured data at a single point in time, it cannot establish cause and effect: women who already feel happy and secure in their relationships may simply feel more comfortable exploring a wider variety of activities with their partners, while women experiencing an unfulfilling partnered sex life may turn to solo masturbation and try more solo techniques to compensate. In addition, sexual satisfaction was measured with a single question about a respondent’s overall sex life, which many people may naturally judge based on their partnered relationships rather than their solo habits. The large sample size also makes it possible to detect tiny statistical differences that have little practical impact in daily life.
The sample consisted of English-speaking users of a health tracking app who were mostly young, White, and heterosexual, and about half held a bachelor’s degree or higher. Because participants volunteered for a study described as being about female orgasms, they may be more comfortable discussing sex, or more sexually active, than women in general. Four of the authors are employees of Flo Health with equity in the company, and the other three are consultants for it.
The authors suggest that bringing elements of solo sex into partnered encounters, such as open communication about preferences and less pressure to perform, could help narrow the gap between solo and partnered orgasms. Future research tracking couples over time could help explain how emotional closeness, trust, and communication interact with physical stimulation to shape sexual fulfillment.
The study, “Sexual Satisfaction and Orgasm Experiences During Partnered and Solo Sex Among 27,931 Users of the Flo App,” was authored by Yella Hewings-Martin, Adam C. Cunningham, Jordan Rullo, Karen L. Blair, Carley Prentice, Anna Klepchukova, and Liudmila Zhaunova.

URL: https://www.psypost.org/women-reach-orgasm-more-often-alone-but-partnered-orgasms-are-more-closely-tied-to-sexual-satisfaction/
-------------------------------------------------
Private, vetted email list for mental health professionals: https://www.clinicians-exchange.org
Unofficial Psychology Today Xitter to toot feed at Psych Today Unofficial Bot @PTUnofficialBot
-------------------------------------------------
#psychology #counseling #socialwork #psychotherapy @psychotherapist @psychotherapists @psychology @socialpsych @socialwork @psychiatry #mentalhealth #psychiatry #healthcare #depression #psychotherapist #SexualHealth #SexualWellness #WomensHealth #FemaleOrgasm #SexualSatisfaction #OrgasmGap #Intimacy #HealthyRelationships #SexualityResearch #HealthResearch

#psychology #counseling #socialwork #psychotherapy #mentalhealth #psychiatry
Psychology News Robot @[email protected]
2026-10-26

DATE: October 26, 2026 at 02:00PM
SOURCE: PSYPOST.ORG
** Research quality varies widely from fantastic to small exploratory studies. Please check research methods when conclusions are very important to you. **
-------------------------------------------------
TITLE: Feed recommendations are the most common way teens encounter self-harm content
URL: https://www.psypost.org/feed-recommendations-are-the-most-common-way-teens-encounter-self-harm-content/
An analysis of data from the 2025 OxWell Student Survey found that about a third of 11- to 18-year-old students in England had come across self-harm content online in the past month. Most of these encounters were unintentional, and about two-thirds of exposed students said the content had appeared in their social media feeds or been suggested while they were browsing. Students who were lonelier, had experienced other online harms, or had poorer mental health were more likely to report exposure. The paper was published in Nature Mental Health.
Social media has become an integral part of young people’s everyday lives. It provides wide opportunities for communication, entertainment, self-expression, and social connection. Platforms such as TikTok and Instagram offer an almost endless stream of content, much of which is selected by recommendation algorithms that personalize what users see based on their interests and online behavior.
While this personalization can help users discover content they enjoy, it can also expose them to potentially harmful material. One particular concern is content related to self-harm, which can range from personal stories of recovery and supportive discussions to graphic images and videos that portray self-injury in a positive or encouraging way.
Research suggests that repeated exposure to such content may increase emotional distress and the risk of self-harming thoughts and behaviors, particularly among vulnerable adolescents. However, the effects are not always negative, as some online communities that discuss self-harm also provide emotional support and encourage young people to seek help.
Adolescents also do not need to search for self-harm content to encounter it, as recommendation algorithms may place it in their feeds without them seeking it out. Their interactions with such content may then lead algorithms to recommend more similar material, potentially creating a cycle of repeated exposure.
Study author Holly Bear of the University of Oxford and colleagues examined how often adolescents in England reported coming across self-harm content online in the past month and the routes through which this happened. They were particularly interested in whether exposure was passive (unintentional) or active, such as searching for the content or having it shared with them, and how these different routes related to students’ demographic characteristics, social experiences, and mental health.
The researchers analyzed data from the 2025 OxWell Student Survey, a school-based survey of young people in England run by researchers at the University of Oxford. The analysis drew on 32,102 students in school years 7 through 13 (ages 11 to 18) at 49 secondary schools and further education colleges, mainly in Liverpool and Oxfordshire, who completed the survey between February and May 2025.
Students were asked whether they had come across content about self-harm on online platforms in the past month and, if so, how. They also answered questions about loneliness, bullying, online aggression and coercion, and symptoms of anxiety and depression. A total of 28,797 students answered the question about exposure, 14,083 of whom were girls.
Of these students, 9,940 (34.5%) reported encountering self-harm content online in the past month. Most of them (55%) had seen it once or twice, while 26.5% had seen it a few times and 18.5% several times.
Among exposed students who described how they came across the content, 66% said it had appeared in their feed or been suggested while they were browsing, and 24% said it was embedded within other, unrelated content. Fewer said they had accidentally encountered it (12%), searched for it (8%), or had it shared with them by someone else (8%), and 15% reported some other route.
Based on these answers, the researchers sorted students into groups. Nearly three-quarters (73%) had been exposed only through passive routes, 12% through a mix of routes, 9% only through “other” routes, 3% only by having the content shared with them, and 3% only by searching for it.
How often students saw the content depended on how they encountered it. Most students exposed only passively (59%) or only through content shared by others (62%) had seen it just once or twice in the past month, compared with about 30% of those who had only searched for it or who were exposed through a mix of routes. The authors note this is consistent with a feedback loop in which actively engaging with self-harm content leads algorithms to show more of it.
Each exposure route was associated with higher levels of loneliness, online harms, anxiety, and depression compared with students who reported no exposure, though the patterns differed across groups. Girls had higher odds than boys of passive-only exposure but lower odds of having content shared with them, and trans and gender-diverse students had elevated odds across most routes, particularly searching for the content.
Black students and students from mixed ethnic backgrounds were more likely than white students to have only searched for the content, as were students who often went to bed hungry compared with those who rarely did. Searching was most strongly linked to depression, while having content shared by others was more closely tied to receiving aggressive or threatening messages online. Students exposed through a mix of routes had some of the most pronounced risk profiles, with especially strong links to online aggression and coercion.
“Exposure to online self-harm content is widespread and shaped by distinct pathways that differ according to adolescents’ wider vulnerabilities, social environments and digital behaviors. Around one-third of our large community sample reported recent exposure, underscoring the need for interventions that account for diverse exposure experiences, from passive, algorithmically driven delivery to more intentional searches and peer sharing,” study authors concluded.
The authors call for a public health approach that combines regulation to reduce self-harm content in feeds, efforts to direct young people who search for it toward supportive resources, and digital literacy education for adolescents and their parents.
The study contributes to the scientific understanding of how adolescents encounter self-harm content online. However, it should be noted that the survey was cross-sectional, so it cannot show whether loneliness, online harms, and mental health difficulties make exposure more likely, result from exposure, or both. The researchers also did not ask what kind of self-harm content students saw, which could range from graphic material to recovery stories and peer support.
In an earlier wave of the survey, about two-thirds of students who had actively sought out self-harm content cited potentially positive motivations, such as finding support or connecting with others with similar experiences. The data were self-reported and came mainly from two regions of England, and the wording of the exposure question, which asked whether students had “come across” such content, may have led some who sought it out to underreport.
The paper, “Algorithmically driven exposure to online self-harm content and its association with broader psychosocial risk in 32,000 adolescents,” was authored by Holly Bear, Emma Soneson, Galit Geulayov, and Mina Fazel.
URL: https://www.psypost.org/feed-recommendations-are-the-most-common-way-teens-encounter-self-harm-content/
-------------------------------------------------
Private, vetted email list for mental health professionals: https://www.clinicians-exchange.org
Unofficial Psychology Today Xitter to toot feed at Psych Today Unofficial Bot @PTUnofficialBot
-------------------------------------------------
#psychology #counseling #socialwork #psychotherapy @psychotherapist @psychotherapists @psychology @socialpsych @socialwork @psychiatry #mentalhealth #psychiatry #healthcare #depression #psychotherapist #TeenMentalHealth #YouthMentalHealth #SocialMedia #RecommendationAlgorithms #OnlineSafety #DigitalWellbeing #SelfHarmAwareness #MentalHealthAwareness #AdolescentHealth #DigitalLiteracy

#psychology #counseling #socialwork #psychotherapy #mentalhealth #psychiatry
Just Sherring @[email protected]
2026-10-26

Yellow Bike

I bought a bike. A yellow bike.
Green is my favorite color. However, 1b is yellow, and 1c is orange. All three give me a rush and calm me, similar to when I enter a bookstore or library. I love wearing all three. They look good on me, especially yellow.
When I finally decide on shades, my kitchen will be painted yellow and my bedroom will be green. My library aka Billy Bookcase’s room, is blue. My childhood favorite color. The employee at the paint store helped me choose Midnight Navy and Lapis. In layman’s terms: dark blue and sky blue. Choosing colors from paint swatches as an adult is the equivalent of choosing crayons from the giant Crayola box. Matter of fact, the bucket.
I spotted Yellow Bike with a “For Sale” sign in a yard parking lot. Yellow frame, seat, and tires. The peanut butter basket and cup holder matched the peanut butter in the center of pedals and tires. It wasn’t until after I brought her home, I noticed a phone holder attached to the cup holder.
I don’t know anything about bikes. Yellow Bike is a Huffy, which was all the rage when I was a kid. Is she vintage? Classic? Old-fashioned? Do they all mean the same thing? I don’t know. They use those terms for cars. I know I had zero plans to buy a bike, just like I know I never want to own a car again. Too much maintenance. That didn’t occur to me with Yellow Bike.
I just know I wanted this bike. Had to have this bike. Specifically because it was yellow and had a basket.
Sometimes the yard gate was closed; other days open. I never spotted anyone. My mind raced at the thought of a guard dog. I mean, there’s always one that comes out of nowhere when someone is trespassing on a lot in the movies.
If one did appear, guaranteed I’d faint and then the dog would maul my face, leaving behind only my glasses. For that reason, I never crossed the threshold into the rocky, in need of repaving lot. But I did take photos, even through the fence. My camera phone did what my glasses could not: zoom in for a clearer picture of Yellow Bike and the phone number on the sign.
I wore this dress to three weddings!My cousin’s wedding, May 2026.
For over a month, I passed Yellow Bike whenever I walked in that direction, particularly when headed to the grocery store.
One day, after a trip to the deli, I took a route home that, in retrospect, made no sense. It was a nice day. I wanted to prolong my walk, even though the extra time meant my hot sandwich was cooling by the second.
I passed by the lot. For the first time, I saw a man. I called out to him as I advanced, hoping there wasn’t a dog. I walked towards Yellow Bike, about 15 feet from the entrance.
“Hello. How much for the bike?” I inquired.
“Dunno. I would ‘af to make a phone cyall.” He whipped out his phone and called the number on the for-sale sign. Something I could’ve and should’ve done weeks ago.
He referred to me as “a young lady wanting to purchase the bike” before switching to speakerphone.
The man on the phone asked for $150. I countered with $120 which he immediately accepted. Well damn, I should’ve pressed for $100. He accepted Zelle. I transferred the money to someone whose name appeared as Snapper in my records.
It was only then I asked to test ride the bike. Backwards, I know, but the adrenaline clouded my thinking.
My heart raced. What if I couldn’t ride? What if I didn’t remember? The kind gentleman told me the bike was perfect for me. We were the right size for each other. Eyeballing me, he said I didn’t even have to adjust the seat, which he claimed was also perfect for me.
I set down my bag containing my hefty Cuban sandwich and my cup of lime chia seed juice.
The kickstand gave way easily enough. I swung my leg over. My heartbeat was in my ears; throat dry. I hadn’t ridden a bike since my trip to Cancun a few years prior, and before that, childhood. Stationary bikes at my weekly NYSC spin class didn’t count. I didn’t have to balance, and I didn’t have to worry about potholes and rocks.
Cancun 2019
I was as wobbly as a fawn learning how to walk. Within seconds, I steadied, but I was heading towards some parked trucks. I’d have to turn, and soon. But there were potholes!
I turned left ready to yell “Timber!” as I tipped over to make light of the situation. By golly! I stayed upright and kept pedaling. I circled another loop.
I flashbacked to when, as a child, me and the boys were only allowed to ride in circles in the driveway. My father moved his Jeep Cherokee to the street to allow more room, warning us not to hit the neighbors’ cars. Their driveway was only separated from ours by an imaginary line. Years later, the line wasn’t imaginary when my father had our side repaved. We had stopped riding bikes by then.
We were stoked when the neighbors’ cars weren’t there, either because they weren’t home or they also moved their cars to give us more room. If not, we’d just ride around.

We raced each other from the end of the driveway that led to the dropped backyard to the imaginary line where the driveway met the sidewalk. About 50 feet. Under no circumstance were we allowed to ride in the street or sidewalk. Not to say that we never did. We lived on an incline. That was too tempting not to try. Going downhill was exhilarating.
When we lived with an aunt in Florida for two years, we rode our bikes everywhere, much to our chagrin. It was embarrassing to ride our bikes, dressed in our Sunday best, to church. Sometimes we rode with Auntie E to the supermarket, so we could help carry grocery bags. Her adult tricycles had rear baskets. Our bikes did not. We had to balance bags on our handlebars.
She admonished us for putting our feet down at intersections. She didn’t grasp the concept of balancing on two wheels versus her three-wheeler.
The only place it wasn’t embarrassing to ride was to school. Lots of other students did. There was a freedom to being able to pedal away from the house of horrors as fast as I could. Wind whipping in my face, my glasses serving as goggles against Florida bugs.
The first time I got called a “nigger” was when I rode by three white boys sitting on a fence. I wondered how they were comfortable sitting on the ragged wire. They weren’t smoking, but in the movie adaptation of my life, I’d feature a single cigarette being passed around for dramatic effect. Add to their bad boy personas, as if teenagers calling a 10-year-old a “nigger” with the hard -ER weren’t bad enough.
It was the 80s. None of us wore helmets. I don’t even think we knew what helmets were.
The proudest moments of our young lives were when we taught ourselves how to ride with one hand. That was topped when we could ride with no hands! Even turning! The boys taught themselves how to pop wheelies.
Now as an adult, an accident-prone one at that, I wouldn’t fathom riding a bike without a helmet. I wore one in Mexico and plan to with Yellow Bike. I had visions of riding with a matching yellow helmet. I want to add yellow and white streamers to the handlebars. I’m all about adding whimsy to my life.
A quick Google search yielded more helmet and sports shops than expected. I fell down a rabbit hole comparing prices and features. Yes, helmets have features! Weight, ventilation, padding, visor, clip vs velcro straps, permanent or attachable front and back light for night vision and visibility, compliance with certified standards for cycling, roller skating, and skateboarding. Mind blown.
I was not expecting those prices. Of course a lifesaving device is $100+, but to spend nearly the same amount of money on the helmet as I did on the bike seemed preposterous. But necessary.
I could go with a less expensive option, but I was set on my olive green and yellow smiley face helmet. With an upcoming trip to Europe, it wasn’t a priority. I added to cart and saved the page.
Yellow Bike sits in the entrance of my apartment. I refuse to pay $15 a month to store it in my building’s bike room. There’s plenty of room for the front door to open. My vintage(?) yellow bike adds to the décor of my apartment. Opposite is my gallery wall featuring art, carved masks, and other souvenirs from visited countries. Other than Billy’s room (my library), it’s my favorite feature of my apartment.
Months later, I have yet to ride Yellow Bike. First, I fell ill with a respiratory virus for weeks. Still recovering, I got hit by a car while walking in a crosswalk.
I was excited the first time I made full rotations on the stationary bike in physical therapy. It meant I was making progress in my healing. I was getting closer to being able to ride Yellow Bike. I ignore the fact that, for now, I’m scared of crosswalks and moving cars.
I still imagine myself wearing my smiley face helmet, dressed in yellow, zipping through the nearby cemetery while the streamers fly. The irony is that I take daily walks there, but next year at this time I’ll be zooming. I already know the lay of the land.
https://www.instagram.com/p/DbHhczwkY5U/?img_index=1
#Adulthood #adventure #Bike #BikeRiding #biking #childhood #cycling #SelfCare #travel #Whimsy #Yellow #YellowBike

#adulthood #adventure #bike #bikeriding #biking #childhood
Allen Hutchison @[email protected]
2026-10-26

Tokens Over Hires

In the middle of September I ran ccusage against every Claude Code session on my laptop since May. It walks the local logs, counts the tokens, and prices them at what the API would have charged. I expected a big number. What came back was about twenty billion tokens and just under fourteen thousand dollars, across every project I’d touched in four months, with most of it going to Pepper, which is now open for signups, so go check it out. Nineteen billion of those tokens were cached reads.
I sat with that for a minute. Fourteen thousand dollars is real money. At my current pace it works out to roughly thirty thousand a year. I could triple it and spend a hundred thousand dollars a year on tokens, and that still isn’t one engineer. In exchange, Chris and I have shipped more code than I’ve shipped in any stretch of my career. I wrote in September that the two of us merged 657 pull requests in our first thirty days with a budget instead of a platform team. When I put the ccusage number in those terms on a panel, it came to about a dollar fifty a pull request.
That number is what my laptop would have cost at API prices, and it isn’t what we actually pay. Here’s the whole bill for both of us. Two Codex subscriptions, one each, are $200 a month. Anthropic is $550 a month: a Max plan for me and Chris, plus two Vycari team seats, one for Chris and one that runs our automation. I have an Ollama subscription at $200 a year. Greptile is about $1,500 a month. All in, that’s a little under $2,300 a month, or about $28,000 a year, for both founders and every pipeline we run. It still isn’t one engineer.
The obvious conclusion is the one a friend reached when he heard the figure: if code is that cheap, just get more tokens. I thought so too, for about a day. Then I looked at what was actually slowing us down, and the token budget wasn’t on the list.
The Constraint Is Attention
Every agent I run needs things from me that tokens can’t buy. It needs a plan approved before it starts. It needs its pull request read when it finishes. When it hits something it can’t decide, it escalates, and somebody has to be there to answer. None of those steps is expensive on its own. The problem is what happens when I run enough agents that the steps overlap.
When I run too many agents, the cost goes up a little and the risk goes up a lot. The biggest thing that’s slipped past us so far was how we managed database connections. It got out of hand, a little at a time, while my attention was on other pull requests, and eventually it caused an outage. Chris had to roll forward while I was out of town, and I spent the following week building a proper database abstraction layer. He put it more bluntly than I would have: the thing that kills us is splitting our attention. That’s when stuff slips through.
When people ask how we decide what to spend, I give them the order. Optimize for human time, because that’s the scarcest thing we have. Then money, because that’s the second scarcest. Then everything around agent time. “I can waste agent time all day. I don’t care.”
So the number that limits us is how many agents one person can supervise well at the same time. I don’t have a precise figure for that ceiling. I know I’ve been over it, because I can feel the difference between a day when every pull request got a real read and a day when I was skimming to keep up.
Another friend told me recently about engineers at his company running up bills in the thousands to build simple internal copies of SaaS tools. His reluctant guess was that they just aren’t as good at using agents yet, and that it’s a skill people have to develop. I don’t know what they’re doing differently. It doesn’t sound like token maxxing, which I’ve never really understood either. I’d love to sit with engineers who run up giant bills and just watch. My guess is they’re using the agents inefficiently, and that what’s missing is supervision, which a bigger budget won’t fix.
Building for More Agents per Person
Almost everything I’ve built since the summer has been an attempt to raise that ceiling, and almost none of it has been about spending less.
The pipeline I described in The Agent That Never Merges is the first piece. Agents open pull requests continuously and never merge them, which means the supervision cost per pull request is bounded at one careful read. The pipeline absorbs the rest: triage, planning, the first round of review comments, the retries. I only see the work once it’s in a state worth my attention.
The second piece is where the work lives. I wrote about pulling Pepper apart into small, bounded repositories to keep CI fast and give agents less to load. It mattered just as much for my attention. An agent working in a repository with one job produces a pull request I can evaluate in one sitting.
We’re up to fourteen repositories now. Last week I moved our iOS app out of the monorepo into its own. That was 150,000 lines of code, and nobody noticed except Chris, who had to wait a day to land his next batch of iOS changes. Agents make refactors that size easy. Having the CLI and the iOS client in their own repositories also forces us to keep good API definitions between the server and its clients.
The third piece is delegation inside the agent layer itself. I run two Claude Opus 5.5 orchestrators on medium effort. One is the UTL, for uber tech lead, and its job is to spawn subagents that build features. The other is what I call the focused worker, and its job is working with me. It catches the manual tasks that come out of the UTL’s pull requests and keeps them in a ledger. Then we work through them together: systems changes, bringing up new platforms, migrating data, anything that needs my level of access and oversight. Everything else goes to a subagent under the UTL, Opus for design docs and code reviews, Sonnet for implementing a feature from a design doc. Every one of these agents can consult a model a tier above it as an advisor, and they all share a wiki for notes.
Anthropic is now advertising much the same pattern with Claude Projects, and I’m happy to see others arriving at the same answer. Chris has been building a loop that babysits open pull requests through review until they score well enough to be worth a human’s time. Each layer like that turns a job I used to do by hand into something I check. The ceiling goes up one delegated task at a time.
The Token Budget Was the Easy Problem
There was a week in September when the meter really was the constraint. We ran through our free credits and paid about $120 in overage. Then AutoDev ate the whole Vycari quota, and I did server cleanup by hand because I couldn’t do anything else.
Most of that was self-inflicted. I’d started with Fable as the orchestrator, with no cap on context, and burned a week’s quota in three days. The setup above fixed it. The orchestrators run on medium effort, and the cheaper model does the implementing. Opus answers the reviews because Sonnet is too literal about them, and a literal reading turns two review cycles into twelve. Every agent auto-compacts at 200K tokens, because Anthropic charges more for context past that point. With that setup, and the work spread across parallel sessions, I find it hard to spend all of my quota. My goal now is to hit 99% of it every week just before it resets. I keep a list of research projects, and if I have quota left 24 hours before the reset, I spin one up. That isn’t the same as maxing out tokens. I’m not trying to use as many as possible. I’m trying to use all the ones I’ve already paid for.
There’s also a second account on the same machine. Claude Code reads a CLAUDE_CONFIG_DIR environment variable, so two shells with two config directories give you two accounts side by side. The second one runs the AutoDev and code review pipelines, and those use up its quota every week, so it isn’t a fallback for my own sessions. When I do run short, I supplement with other labs’ plans. Every one of those fixes took an afternoon or less. None of the supervision problems above has had an afternoon fix.
Where the Money Actually Goes
While I had the numbers in front of me, I looked at where development spend actually lands, because it isn’t where I expected either.
Development tokens currently run about ten times what the product itself consumes, even with real people using it. Building the thing costs more than running it. That won’t last. The feedback from our private beta has been really good, and we now open Pepper to a limited number of new signups every day, so product usage is rising quickly.
Most of what we actually pay goes to code review. Subscriptions are the cheap way to buy tokens if you’re willing to hit limits, so they’re the smaller line. Greptile reviews every pull request we open, and at about $1,500 a month it’s our biggest single expense. We both think it’s worth it, because it’s the layer that lets the never-merge pipeline run without me reading every first draft.
In October I tested that. I spent a few days building a cheaper reviewer to replace it. I came out the other side saying, “I think we should just pay for it because I can’t do it cheaper.” What I could change was how often we call it. The agents kept asking for a re-review before they’d fixed anything. Because every repository shares a common dev environment, the fix went in once: our pull-request skill now has agents run /simplify and then /code-review before they’re allowed to open a pull request. On many of our repositories, our own reviewer also does the first round and only then calls Greptile. My goal is a pipeline where Greptile’s reviews come back with nothing to say. We’re not there yet, but we get a little better every week.
I’d rather pay for review than have a second person do it, and the reason isn’t salary. The person would need supervising too, because review is a job I’d have to check, not one I can hand off.
What a Hire Is For Now
Five years ago, if I’d been getting a product like this ready for market, I’d have been hiring twenty to fifty engineers. The work would have needed that many hands, and most of what they’d have done was write code. Today the code is the cheap part. If I bring someone in to write code, I’ve added a person who needs plans approved and pull requests read, which is the exact resource I’m short on. A hire whose job is output adds coordination faster than it adds capacity.
I said on a podcast that came out last week that the code I’ve written would have cost about fifteen thousand dollars at API prices, and that I couldn’t hire engineers for that money. That’s true. The engineers I’d still want are a different kind from the ones I hired at Google. We need a few more people who can herd agents, not fifty.
The engineering hire that adds capacity is a different shape. It’s someone who can own a bounded service whole. Here’s the interface, here’s everything it needs to do, let me know when it’s done. That person brings their own supervision. They run their own agents, read their own pull requests, and answer their own escalations, and the only thing that crosses the boundary between us is the contract. Supervision divides along the interface instead of piling up on one person. That’s a tech lead’s job, and it’s the only kind of engineering hire I can see that raises the ceiling instead of lengthening the queue.
That raises a fair question about how anyone grows into that job now, which I tried to answer in The Questions Are the Job. The other advice I give is to work on open source. I’ve met people who showed they could work really efficiently with agents through open source projects, Gemini CLI in particular, and some of them ended up being hired onto my teams. Open source has its own problems right now. But if you show up as a thoughtful engineer with features or bug fixes that are well reviewed, well tested, and bring value to the project, I think you’ll be welcome. That’s one of the reasons I decided to open source the Pepper CLI.
The first hire probably isn’t an engineer at all. I’ve said this a few times now, including on stage at a panel in September. Neither Chris nor I are go-to-market people, and I may hire one before I hire another engineer. I can create piles and piles of code, even relatively good code. What I can’t do is agentically acquire customers. (Did I mention that Pepper is open for signups now?) Someone in marketing came up after the panel and told me I’d validated her existence.
The Third Trend
I’ve watched this happen twice before. Open source developer tooling made it so a small team didn’t need to buy or build its own compilers, databases, and frameworks. Cloud infrastructure made it so that team didn’t need to own hardware or a data center. Each time, the number of people you needed to start something real dropped, and the skills that mattered shifted toward the people who understood systems well enough to compose what was suddenly free.
Agentic tools are the third one. Anyone with a good idea can now get from concept to production on a budget that would have been a rounding error in a Google planning cycle. But the constraint didn’t vanish. It moved, the same way it did the last two times, toward the people who understand systems design well enough to drive the agents and notice when something has slipped through. I wrote a year ago that management skills were going to carry over to working with agents. I didn’t expect to be proving it with a two-person org chart and fourteen thousand dollars of tokens.
This isn’t only a small-company problem. At Google it was hard to get more than a few changes in a day, because each one waited on code review. I’ve talked to engineers there who now do all their work in experimental directories that don’t require review, then port it back to their team’s repository at a pace the review process can keep up with. That’s what happens when you don’t manage for human attention. Productive people spend their cycles waiting on the process.
When other companies ask me what to change, my answer has become: drive until human attention is the scarce resource, then build for that. If you’re reading your own ccusage number and wondering whether the answer is more tokens, look at where your attention went first. For us the answer has been more interfaces. Those are the places where one person’s supervision ends and another’s begins, or where an agent takes over a job one of us used to do by hand.
#Agents #AI #Developer #Startups

#startups #developer #ai #agents
Dev Community @[email protected]
2026-10-26
An agent that goes quiet for ten minutes does not feel autonomous. It feels broken. A spinner and a made-up “82% complete” label are not much better: they encourage users to trust a number your system cannot justify.
The fix is not to stream the model's hidden reasoning. It is to publish a small, evidence-backed account of the work: what phase the run is in, the last verified milestone, whether it needs a person, and what will happen next. This article shows how to build that contract for long-running, tool-using AI agents.
The progress problem is really a trust problem

Users ask three practical questions while an agent runs:
Is it still alive?
Did it make meaningful progress?
Do I need to do anything?
A token stream answers none of these reliably. It can continue while a tool is stuck, and it can stop even though a durable workflow will resume later. Likewise, an LLM-generated status such as “almost finished” is a prediction, not evidence.
Treat status as a product contract. The user-facing timeline should be derived from workflow events your system can verify: a job was accepted, a connector returned records, validation passed, an approval is waiting, or a final artifact was stored. The model may suggest a label, but it should not be the source of truth for state.
This distinction also protects privacy. A useful update is “Checked 42 invoices; 3 need review,” not a transcript of the agent's scratch work, retrieved customer text, or chain of thought.
Start with a state machine, not a progress bar

Long-running agent work has more states than running and failed. Model the states explicitly and make transitions durable.
StateMeaning to the userRequired evidenceUseful UI actionqueuedWork is accepted but has not startedrun record createdCancelrunningA worker currently owns the runlease heartbeatStopwaiting_on_toolThe run is awaiting a bounded external calltool request ID and deadlineCancelwaiting_on_userA decision or missing input is requiredapproval or question IDReview / answerretry_scheduledThe system will retry laterretry time and error classCancel / view detailssucceededThe requested result was verified and savedoutput receiptOpen resultfailedThe run cannot continue automaticallyfailure class and last checkpointRetry / contact supportcancelledWork was intentionally stoppedcancellation receiptRestart

Avoid a vague paused state. If the workflow is paused because it needs an address, show waiting_on_user. If it is paused because a vendor rate-limited it, show retry_scheduled. Specific state names let a user decide what to do without reading logs.
Here is a compact TypeScript event shape. It is deliberately about observable work, not hidden reasoning.
type RunEvent = {
runId: string;
sequence: number; // monotonic per run
at: string;
type: "phase_started" | "milestone" | "approval_needed" |
"retry_scheduled" | "completed" | "failed";
phase?: "preparing" | "collecting" | "verifying" | "delivering";
message: string; // reviewed, user-safe copy
evidence?: {
kind: "artifact" | "tool_receipt" | "checkpoint" | "approval";
id: string;
};
action?: { label: string; url: string };
};
Persist these events in the same transaction that changes workflow state, or attach them to an outbox. A UI event that says “report ready” before the report is stored is worse than no event at all.
Publish milestones, not a narrated thought process

Choose milestones at boundaries where the system can prove something changed. Good milestones are stable across model versions and useful if a run resumes tomorrow.
For a document-analysis agent, the timeline might be:
Request accepted
Source file scanned and indexed
42 records extracted
Policy checks completed
Three exceptions need a decision
Final report saved
Notice what is absent: “thinking about clause 7” or “I believe this source is probably relevant.” Those claims are neither a dependable progress signal nor an appropriate audit record.
Each milestone needs an owner. The workflow engine owns checkpoint messages; the connector owns data-fetch receipts; the policy service owns validation results. If no component can produce evidence for an update, leave it out.
That rule prevents a common failure mode: a chat interface keeps emitting cheerful prose while the actual job stopped moving. Your supervisor should detect stale progress independently of the agent. For example, mark a run stalled internally when its lease heartbeat is fresh but neither a checkpoint nor a tool receipt has advanced within the expected phase window. The user-facing text can then say, “Still working longer than expected; no action needed yet,” or escalate honestly to “This task needs attention.”
Design an honest progress model

Percent complete works only when units of work are known. A migration over 10,000 rows has a denominator. An open-ended research task generally does not.
Use one of these models instead:
Work shapeBest indicatorExampleFixed batchcompleted / total318 of 500 files checkedKnown workflowcompleted phaseVerifying findings (3 of 4 phases)Open-ended workelapsed time plus latest verified eventLast verified update: sources indexedApproval flowblocked state and decision impactNeeds approval before sending 3 emailsRetryable external worknext retry and preserved checkpointRetrying connector at 14:05; 18 items saved

Do not convert phase count into a false percentage. Four phases do not necessarily take equal time, and the model can loop inside one phase. If you show an estimate, label it as a range derived from similar completed runs, and hide it when the sample is weak.
function statusCopy(run: Run) {
if (run.status === "waiting_on_user")
return "Your decision is needed before this task can continue.";
if (run.completedUnits != null && run.totalUnits != null)
return `${run.completedUnits} of ${run.totalUnits} items verified`;
return `Last verified update: ${run.latestMilestone.message}`;
}
The word verified matters. It teaches users what the timeline represents and sets a standard your team can test.
Make waiting visible and actionable

The most damaging silence is not a slow model call. It is an agent waiting for a person while the product looks busy.
An approval event should include the decision, the consequence, the safe default, and an expiry rule. Keep the payload concise and reviewable:
{
"type": "approval_needed",
"message": "Three customer records have conflicting addresses.",
"question": "Which address should be used for the renewal notice?",
"options": ["CRM record", "latest support ticket", "skip these records"],
"default": "skip these records",
"expires_at": "2026-10-26T15:00:00Z",
"evidence": { "kind": "approval", "id": "apr_8f2" }
}
Never bury an approval in a scrolling chat. Surface it as a run state, send a notification only when action is required, and ensure a resumed run re-reads the approved decision from durable storage. This pairs well with approval gates, but it solves a different problem: making the wait understandable to the person who initiated the work.
Transport updates without building a fragile realtime system

Start with the simplest transport that fits your product.
Polling is enough for minute-scale background jobs. Return status, latest_event, and etag; back off when nothing changes.
Server-sent events work well for one-way timelines and reconnect cleanly with Last-Event-ID.
WebSockets fit collaborative workspaces where users can also approve, stop, or redirect a run live.
Notifications should be sparse: completion, failure, and waiting_on_user are normally worth interrupting someone; routine milestones are not.
Regardless of transport, the client must tolerate duplicate and out-of-order events. Use the sequence field, make the event stream append-only, and fetch the authoritative run snapshot after reconnecting. The UI is a projection; the workflow database remains the authority.
Build the API around a durable run record

A small API surface is easier to secure and test than a channel full of ad hoc text.
GET /runs/run_123
{
"status": "waiting_on_user",
"phase": "verifying",
"latest_event_sequence": 17,
"latest_event": {
"message": "42 records verified; 3 need a decision",
"at": "2026-10-26T12:04:12Z"
},
"actions": [{ "kind": "approve", "approval_id": "apr_8f2" }]
}
Keep sensitive tool arguments, raw documents, and internal exception stacks behind a permissioned diagnostics view. The default run page should disclose only the minimum a user needs to understand progress and take the next action.
Test the status contract like an API

Status is part of the user experience, so add tests beyond the happy path:
A run cannot become succeeded without an output receipt.
A waiting_on_user run always exposes a decision action and cannot spend tools until it resumes.
Replayed events create the same final timeline.
A reconnect receives no duplicate visible milestones.
A cancelled run cannot later publish a success event.
A stale worker lease produces an honest recovery state, not permanent “Working…” copy.
User-safe messages contain no prompt, secret, customer text, or chain of thought.
it("does not claim success before output exists", async () => {
await workflow.emit({ type: "completed", evidence: undefined });
expect(await runs.get("run_123")).toMatchObject({ status: "failed" });
});
This is also where observability earns its keep. Measure time to first verified milestone, time spent waiting for users, stale-run recovery rate, and the share of runs that finish with a useful artifact. Avoid treating the number of progress messages as a health metric; a noisy timeline can conceal a poor workflow.
A practical rollout plan

Do not retrofit every agent at once. Start with one workflow where users currently refresh a page or ask support whether a job is stuck.
Define the state machine and ownership of each transition.
Add durable run records and one evidence-backed milestone per phase.
Replace generic spinners with the latest verified update.
Promote approval waits to a clear, resumable state.
Add stale-run detection and a recovery message.
Instrument completion quality, not just elapsed time.
The result is deliberately less theatrical than a stream of simulated thinking. It is far more useful: people can leave a long-running agent alone, return with context, and intervene exactly when their judgment is needed.
Keep the language stable across releases

Treat visible status copy as part of your API. Changing waiting_on_user from “Needs your decision” to “Paused” may seem cosmetic, yet it can break notification rules, customer runbooks, and accessibility labels. Version the event schema, localize messages at the presentation layer, and keep a small compatibility test suite for every public state. That discipline pays off when new models, tools, and workflow engines arrive: the user still receives the same clear promise about what has happened and what they can do next.
FAQ
Should an AI agent show its chain of thought as progress?

No. Show concise, evidence-backed milestones instead. They are more reliable, safer for sensitive data, and easier for users to act on.
How often should an agent send status updates?

Update on meaningful state changes, verified milestones, and action-required moments. For long silent phases, add a bounded heartbeat that says the job is still owned, not a stream of filler messages.
Is a percentage complete useful for AI agents?

Only when the work has a known denominator, such as files processed or records checked. Otherwise show the phase, elapsed time, and most recent verified milestone.
What is the best state for an agent waiting on a person?

Use a specific waiting_on_user state with the exact question, a safe default, and a resumable approval ID. Do not leave the run labeled running.
Can polling work for long-running AI workflows?

Yes. Polling is simple and reliable for background tasks that update every few seconds or minutes. Use ETags and backoff, then move to SSE or WebSockets only when the interaction requires it.
How do you detect an AI agent that is stuck?

Track worker leases, tool deadlines, and the time since the last verified milestone. A supervisor outside the model should classify stale runs and surface a recovery state.#ai #ux #programming #devops #software #coding #development #engineering #inclusive #community
AI Agent Status Updates: Build Progress Users Can Trust Without Exposing Chain of Thought
#devops #ai #community #programming #software #ux
Dev Community @[email protected]
2026-10-26
The Problem With "Free" Online PDF Converters
If you have ever used a standard online PDF compressor, converter, or merger, you have almost certainly uploaded your documents to a third-party server. In many cases, that is an unacceptable risk. Typical PDF payloads contain sensitive data:
Executed contracts and legal agreements
Patient medical records and diagnoses
Banking, tax, and financial statements
Proprietary internal company documentation
When uploaded, that data travels across external networks, lands on third-party file systems (often indefinitely), and is processed by infrastructure you cannot audit.
We set out to build a different model: a document processing suite where files never leave the user device. Here is the technical stack and architecture that makes client-side PDF execution possible.
Architecture Overview
┌─────────────────────────────────────────────┐
│ Browser │
│ │
│ ┌──────────┐ ┌──────────────────────┐ │
│ │ File API │───▶│ WebAssembly Module │ │
│ └──────────┘ │ (pdf-lib / PDF.js / │ │
│ │ custom WASM binary) │ │
│ ┌──────────┐ └──────────┬───────────┘ │
│ │ Canvas │◀──────────────┘ │
│ │ Blob │ │
│ │ URL │ │
│ └──────────┘ │
└─────────────────────────────────────────────┘
↕ Zero network requests for file data
All heavy tasks execute inside dedicated Web Workers to ensure the main UI thread stays at a fluid 60 FPS. Once processing finishes, the output is converted into an in-memory Blob URL and handed directly to the user for immediate download. Not a single byte of file content is sent over the wire.
Core Stack
Layer Technology
PDF parsing & manipulation pdf-lib + PDF.js
Computation offloading Dedicated Web Workers
Image compression (WASM) @jsquash/mozjpeg + @jsquash/webp
Application framework Next.js (App Router)
State management React useReducer + useRef
Step 1: Reading PDFs with the HTML5 File API
The first milestone is reading document bytes into local browser memory without triggering network activity:
javascript
// Local memory read — zero network interaction
async function readPDFFile(file) {
return new Promise((resolve, reject) => {
const reader = new FileReader();
reader.onload = (e) => resolve(e.target.result); // ArrayBuffer
reader.onerror = reject;
reader.readAsArrayBuffer(file);
});
}
// Event handler
const input = document.getElementById('file-input');
input.addEventListener('change', async (e) => {
const file = e.target.files[0];
const buffer = await readPDFFile(file);
// buffer is an ArrayBuffer allocated strictly in local client memory
processPDF(buffer);
});
Using FileReader.readAsArrayBuffer() provides raw byte access inside JavaScript memory. From this point forward, every operation operates strictly as local computation.
Step 2: Document Manipulation via pdf-lib
pdf-lib is a standalone JavaScript library that runs natively in the browser without any Node.js runtime or server dependencies. Here is how document merging is implemented client-side:
javascript
import { PDFDocument } from 'pdf-lib';
async function mergePDFs(arrayBuffers) {
// Initialize a new empty PDF document
const mergedPdf = await PDFDocument.create();
for (const buffer of arrayBuffers) {
// Load each PDF from ArrayBuffer in memory
const sourcePdf = await PDFDocument.load(buffer);
// Copy all pages into the merged target document
const pages = await mergedPdf.copyPages(
sourcePdf,
sourcePdf.getPageIndices()
);
pages.forEach((page) => mergedPdf.addPage(page));
}
// Serialize to Uint8Array within client memory
const mergedBytes = await mergedPdf.save();
// Create an instant download URL without remote servers
return URL.createObjectURL(
new Blob([mergedBytes], { type: 'application/pdf' })
);
}
This entire merge cycle runs synchronously in memory without a single outbound network packet.
Step 3: Offloading Computation to Web Workers
PDF serialization and parsing can easily freeze the main JavaScript thread on documents with hundreds of pages. We isolate all computation inside a background Web Worker:
javascript
// worker.js
import { PDFDocument } from 'pdf-lib';
self.onmessage = async ({ data }) => {
const { type, payload } = data;
try {
switch (type) {
case 'COMPRESS': {
const result = await compressPDF(payload.buffer, payload.quality);
// Transfer the ArrayBuffer back (zero-copy memory transfer)
self.postMessage({ success: true, buffer: result }, [result]);
break;
}
case 'MERGE': {
const result = await mergePDFs(payload.buffers);
self.postMessage({ success: true, buffer: result }, [result]);
break;
}
}
} catch (err) {
self.postMessage({ success: false, error: err.message });
}
};
javascript
// main thread
const worker = new Worker(new URL('./worker.js', import.meta.url));
function processPDFInWorker(buffer) {
return new Promise((resolve, reject) => {
worker.postMessage(
{ type: 'COMPRESS', payload: { buffer, quality: 0.8 } },
[buffer] // Transferable object: passes pointer without memory duplication
);
worker.onmessage = ({ data }) => {
if (data.success) resolve(data.buffer);
else reject(new Error(data.error));
};
});
}
By specifying [buffer] in the transfer list, ownership of the memory block is transferred instantly to the worker thread without invoking expensive structured clone copying.
Step 4: PDF Compression with WebAssembly Codecs
File sizes in scanned or multi-page documents are predominantly caused by embedded raster images. Effective compression requires:
Rendering each PDF page to an offscreen canvas
Re-encoding the canvas pixels using WebAssembly-compiled image encoders
Re-assembling the PDF with re-quantized image streams
javascript
import { getDocument } from 'pdfjs-dist';
import * as mozjpeg from '@jsquash/mozjpeg';
async function compressPDFImages(buffer, quality = 0.75) {
const pdfDoc = await getDocument({ data: buffer }).promise;
const newPdf = await PDFDocument.create();
for (let i = 1; i <= pdfDoc.numPages; i++) {
const page = await pdfDoc.getPage(i);
const viewport = page.getViewport({ scale: 1.5 }); // Target 144 DPI
// Render to OffscreenCanvas without needing DOM bindings
const canvas = new OffscreenCanvas(
viewport.width,
viewport.height
);
const ctx = canvas.getContext('2d');
await page.render({ canvasContext: ctx, viewport }).promise;
// Extract raw image data
const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
// Encode via MozJPEG WebAssembly
const compressedBytes = await mozjpeg.encode(imageData, { quality: quality * 100 });
// Embed back into destination document
const jpgImage = await newPdf.embedJpg(compressedBytes);
const newPage = newPdf.addPage([viewport.width, viewport.height]);
newPage.drawImage(jpgImage, {
x: 0, y: 0,
width: viewport.width,
height: viewport.height,
});
}
return await newPdf.save();
}
Why MozJPEG over Native Canvas Encoders?
Browser native canvas toBlob() implementations prioritize encoding speed over file size compression. MozJPEG compiled to WebAssembly consistently produces 30% to 50% smaller image files at equivalent perceptual quality metrics (SSIM and PSNR). The gzipped WASM module weighs only around 200 KB and runs near native execution speeds.
Performance Benchmarks
Benchmark performed on a 10-page scanned color document (original payload: 8.2 MB):
Processing Method Output Size Visual Fidelity Duration
Native canvas.toBlob() (quality 0.8) 4.1 MB Good 1.2s
MozJPEG WASM (quality 75) 2.3 MB Sharp 1.8s
MozJPEG WASM (quality 60) 1.4 MB Acceptable 1.8s
Server-side Ghostscript engine 1.1 MB Good ~3s + upload transit
The client-side WASM pipeline approaches within 30% of server-side Ghostscript performance while completely eradicating upload latency and security risks.
Step 5: Memory Management and Streaming
When loading a 50 MB document, naïve implementations can easily inflate memory usage to over 200 MB due to multiple concurrent representations (ArrayBuffer, parsed AST, canvas pixel arrays).
To prevent tab crashes on memory-constrained devices:
javascript
// Stream processing: parse and clean page-by-page
async function* streamPages(buffer) {
const pdfDoc = await getDocument({ data: buffer }).promise;
for (let i = 1; i <= pdfDoc.numPages; i++) {
const page = await pdfDoc.getPage(i);
yield page;
// Explicitly evict page cache from PDF.js internal store
page.cleanup();
}
}
// Bounded heap iteration
for await (const page of streamPages(buffer)) {
await processPage(page);
}
For files exceeding 100 MB, the application advises splitting the document before applying compression or conversions — a pattern supported directly in KAOpdf Split PDF.
Handling Edge Cases
Password-Protected Documents
javascript
async function loadProtectedPDF(buffer, password) {
try {
return await PDFDocument.load(buffer, {
password,
ignoreEncryption: false
});
} catch (err) {
if (err.message.includes('password')) {
throw new Error('Incorrect password entered.');
}
if (err.message.includes('encrypted')) {
throw new Error('Unsupported encryption standard (256-bit AES).');
}
throw err;
}
}
Corrupted or Non-Standard PDF Streams
PDF.js is significantly more tolerant of damaged cross-reference tables than strict parsers. When structural modification fails in pdf-lib, we fall back to PDF.js rendering:
javascript
async function robustLoad(buffer) {
try {
return await PDFDocument.load(buffer);
} catch {
// Fallback: render damaged pages via PDF.js and reconstruct
const pdfJsDoc = await getDocument({
data: buffer,
stopAtErrors: false
}).promise;
return rebuildFromRenderedPages(pdfJsDoc);
}
}
Security Model and HTTP Headers
Moving processing to the client eliminates data breach vectors on the backend, but requires strict client-side browser controls.
Security Guarantees
Zero server breach exposure for uploaded files
Immunity to man-in-the-middle transmission interception
Zero regulatory storage liability (GDPR, HIPAA compliance by design)
Client Configuration Requirements
To enable high-performance multithreaded WASM and SharedArrayBuffer, modern browsers mandate Cross-Origin Isolation headers:
javascript
// next.config.js — Cross-Origin Isolation headers
const nextConfig = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{ key: 'Cross-Origin-Opener-Policy', value: 'same-origin' },
{ key: 'Cross-Origin-Embedder-Policy', value: 'require-corp' },
],
},
];
},
};
Production Implementation at KAOpdf
This architecture is currently running live in production across more than 35 web-based tools on KAOpdf:
Compress PDF — MozJPEG WebAssembly quantization
Merge PDF — In-memory page aggregation
Split PDF — Client-side page extraction
OCR PDF — Offline Tesseract.js WASM character recognition
AI PDF Summarizer — On-device WebGPU model execution
Across all tools, the fundamental contract remains unchanged: zero file uploads, zero remote storage, and complete user privacy.
Engineering Takeaways
1.pdf-lib for structure, PDF.js for rendering: pdf-lib handles fast document generation, while PDF.js is the most resilient parser for non-standard PDFs.
2.Transferables are mandatory: Always pass ArrayBuffers in worker transfer lists to prevent costly memory duplication.
WebAssembly image codecs deliver real gains: WASM-compiled MozJPEG consistently beats native browser canvas encoders in compression efficiency.
Enforce bounded memory loops: Always call .cleanup() after rendering pages to prevent tab crashes on mobile browsers.
Resources and Documentation
pdf-lib Documentation
pdfjs-dist on npm
@jsquash/mozjpeg on npm
KAOpdf Live Tools
If you are experimenting with client-side document processing or running into WebAssembly memory bottlenecks, feel free to share your thoughts or questions in the discussion below.#webassembly #ai #pdf #webdev #software #coding #development #engineering #inclusive #community
How I Built a Privacy-First PDF Processor That Never Uploads Your Files
#ai #community #software #webdev #coding #pdf
Psychology News Robot @[email protected]
2026-10-25

DATE: October 25, 2026 at 06:00AM
SOURCE: PSYPOST.ORG
** Research quality varies widely from fantastic to small exploratory studies. Please check research methods when conclusions are very important to you. **
-------------------------------------------------
TITLE: Your body makes its own cannabis-like chemicals as you run, and neuroscience research finds they keep rising all the way to the marathon finish line, a possible clue to the runner’s high
URL: https://www.psypost.org/your-body-makes-its-own-cannabis-like-chemicals-as-you-run-and-neuroscience-research-finds-they-keep-rising-all-the-way-to-the-marathon-finish-line-a-possible-clue-to-the-runners-high/
A long run appears to keep the body’s own cannabis-like chemical messengers active for hours. New research published in BMC Medicine indicates that one of these compounds, anandamide, climbs steadily during a marathon and stays elevated 45 minutes after the finish, and that levels are also higher after ultramarathons of up to 230 kilometers. These chemical changes occurred alongside shifts in mood, such as reduced anxiety after running, although the study did not test whether one caused the other.
The runner’s high is a state some people report during or after endurance exercise, marked by euphoria, reduced anxiety, less pain, and a sense of calm afterward. Early explanations credited endorphins, the body’s natural opioid painkillers, but endorphins are large, water-soluble molecules, and there is no convincing evidence that they cross the blood-brain barrier, the protective filter between the bloodstream and the brain, in meaningful amounts.
Endocannabinoids offer an alternative: they are small, fat-soluble molecules made on demand from cell membranes, they can cross that barrier, and they act on the same cannabinoid receptors targeted by THC, the main psychoactive compound in cannabis. The two best studied are anandamide and 2-arachidonoylglycerol, often shortened to 2-AG.
Laboratory experiments began supporting this shift in thinking when a 2015 animal experiment led by Johannes Fuss, the senior author of the new study, showed that wheel-running mice relied on cannabinoid receptors, rather than opioid receptors, to experience reduced anxiety and lower pain sensitivity. Human research soon followed, including a 2021 clinical trial by the same group where researchers gave participants a medication that blocked opioid receptors. The runners still reported the typical calm and euphoric sensations of a runner’s high, suggesting that endorphins were not required for those effects.
In a 2022 systematic review, the same group found that 14 of 17 studies detected a rise in endocannabinoids after a single bout of exercise. But as the authors of the new study note, nearly all of that human research involved workouts lasting under an hour, leaving open what happens during true long-distance events.
“Humans are capable of running for many hours, sometimes even days, and we wanted to understand what happens to the endocannabinoid system during such extraordinary endurance efforts,” lead author Michael Siebers, a psychiatrist at LVR University Hospital Essen, told PsyPost.
“I believe that our ability to run long distances cannot be explained by anatomy alone,” Siebers explained. “We probably also need an entire orchestra of neuromodulators that reward us for sustained physical activity and help us continue running despite fatigue and discomfort. Thanks to a wonderful collaboration with researchers from Ulm and the German Sport University Cologne, we were able to investigate these processes during marathon and ultramarathon running, including distances of up to 230 kilometers.”
To investigate these biochemical and emotional shifts under real-world conditions, Siebers and his colleagues, including senior author Johannes Fuss of the University of Duisburg-Essen and collaborators at University Hospital Ulm and the German Sport University Cologne, designed two field studies of trained endurance athletes.
The first investigation examined 19 experienced runners, including seven women and 12 men, who completed a marathon course consisting of three 14-kilometer loops around Lake Baldeney in Essen, Germany. To establish a realistic comparison, each runner returned one to two months later to complete an identical-duration walking session along the same route at their preferred pace. Blood samples were drawn at the start, at the 14-kilometer and 28-kilometer marks, immediately after the full course (about 43 kilometers), and after a 45-minute rest period. Alongside blood draws, participants completed visual rating scales to score their current levels of euphoria, anxiety, and physical pain.
The second investigation followed 36 athletes (16 ran 100 kilometers, 7 ran 160, and 13 ran 230) taking part in the TorTour de Ruhr, a non-stop ultramarathon in central Germany. These athletes, comprising 13 women and 23 men, provided blood samples and mood ratings before the race and shortly after crossing the finish line. In both studies, laboratory technicians measured several key lipids, including anandamide and 2-AG.
In the marathon study, levels of anandamide rose progressively across the entire run. By the mid-race mark, anandamide was higher during running than during walking, which produced only modest changes, and it remained higher 45 minutes after the marathon ended. Running was also far more intense, with runners averaging about 83 percent of their estimated maximum heart rate, compared with about 58 percent while walking. The compound 2-AG displayed a different trajectory, showing lower levels early in the run compared to walking, but climbing during the final kilometers and staying elevated during early recovery.
The ultramarathon runners exhibited similar biochemical patterns upon completing their races. Anandamide and 2-AG concentrations were both higher after the race across all three ultramarathon distances compared to pre-race baselines. In an exploratory comparison, post-race anandamide levels after the marathon were nearly double those seen after the ultramarathons (32.4 versus 17.1 in the study’s measurements), which the authors suggest may reflect the higher running intensity of the shorter race.
Mood ratings also shifted during running. Marathon participants reported higher euphoria while running than while walking at several points, although at the 28-kilometer mark, a stage where runners often describe “hitting the wall,” euphoria was no longer different from walking. Anxiety ratings started slightly higher before the marathon than before the walk, then fell toward the end of the run, and pain ratings showed little change after 14 kilometers but rose markedly from 28 kilometers on. In the ultramarathon group, anxiety decreased after the race, more so at 100 and 160 kilometers than at 230, while pain rose and euphoria did not change in a statistically significant way.
When asked afterward, only 3 of the 19 marathoners said they had experienced a runner’s high during the marathon, while 8 said they had not and 8 were unsure; among the ultramarathoners, 12 said they had and 19 said they had not.
The findings are in line with research covered by PsyPost in 2022, which found that acute exercise consistently increased endocannabinoid levels, especially anandamide, with moderate intensity yielding stronger boosts than low intensity.
“This is an interesting study, particularly because it’s not easy to investigate physiological responses to exercise over marathon and ultramarathon distances,” said Danielle McCartney, a research affiliate at the University of Sydney who was not involved in the study. “The key finding is that circulating concentrations of anandamide (AEA), an endocannabinoid, increased progressively throughout the marathon and were also elevated following ultramarathons of 100, 160 and 230 km.”
“Previous studies have consistently shown that moderate-intensity running increases blood concentrations of AEA,” McCartney told PsyPost. “However, most of this research has focused on relatively short bouts of exercise (less than 60 minutes). This study fills an important gap by examining much longer running distances, and shows that increases in AEA also occur during marathon and ultramarathon running.”
The researchers see the sustained activity as a possible clue to how humans manage hours of running.
“One of our most important findings is that the body’s own cannabinoid system remains active even during extremely prolonged exercise,” Siebers noted. “We observed substantial increases in endocannabinoids, particularly anandamide, not only during marathon running but also after ultramarathons lasting many hours.”
“These molecules are sometimes described as the body’s own cannabis-like substances because they act on the same cannabinoid receptor system targeted by THC,” he said. “They may contribute to the rewarding, calming, and potentially pain-modulating effects of running. From an evolutionary perspective, I find this particularly fascinating. Humans have an extraordinary capacity for endurance running, and the endocannabinoid system may be one of the biological mechanisms that make prolonged running not only physically possible but also psychologically rewarding.”
Siebers described the shift many runners report over the course of a run.
“At the beginning of a run, everything may feel uncomfortable,” he observed. “Your calves are aching, your back feels stiff, and every step requires some effort.”
“But after a while, something can change,” he noted. “Your movements become smoother, running feels increasingly effortless, and you may enter a state of flow. Sometimes this develops into euphoria, while everyday worries and stress seem to fade into the background.”
Siebers also sees potential relevance for mental health.
“As a psychiatrist, I find this especially interesting because running can become a valuable tool for coping with stress, improving mood, and supporting mental well-being,” he added. “Of course, exercise is not a replacement for professional treatment when it is needed, but for some people, it can be an important part of their recovery and everyday life.”
The study did not test whether runners whose anandamide rose the most felt the most euphoric or calm.
McCartney cautioned, however, against assuming that these chemical increases directly generate the emotional sensations reported by participants. “It’s important to recognize that this study doesn’t establish that increases in AEA are responsible for the ‘runner’s high,'” she explained. “It shows that prolonged running increases blood AEA concentrations and is associated with changes in mood, including increased euphoria and reduced anxiety. While these findings are consistent with the idea that AEA contributes to the runner’s high, they don’t establish a causal relationship.”
The TorTour de Ruhr presented extreme physical demands, requiring runners to navigate unfamiliar routes for up to 230 kilometers, often through the night and in isolation.
“What impressed me most was witnessing what humans are capable of achieving,” Siebers recounted. “Some of our participants ran distances of up to 230 kilometers, maintaining their effort for many hours, sometimes running alone through the night on unfamiliar trails. Equally fascinating was the atmosphere among the ultramarathon runners. Despite the enormous physical demands, there was a remarkable sense of community and positivity.”
“I was particularly struck by participants who reported very little anxiety after these extraordinary distances, even after spending hours alone in unfamiliar surroundings,” he said. “Some runners also reported surprisingly little pain despite covering distances that would seem almost unimaginable to most people. These observations make me wonder how strongly our internal neuromodulatory systems can influence the way we experience physical effort, pain, and fear.”
Pain was still common: 29 of the 36 ultramarathoners reported pain during the race, only five reported none, and eight said they used pain medication, particularly in the longest race.
As with all research, there are some caveats to consider. The marathon study used walking as a comparison rather than having participants sit quietly, meaning the control condition still involved mild physical exertion. Participants also selected their own running and walking speeds, which preserved a realistic race environment but introduced variation in how hard each individual was working.
“I have reasonable confidence in the main findings, particularly because the increases in AEA were consistent across the marathon and ultramarathon studies and align with previous research,” McCartney told PsyPost. “However, there are some limitations worth considering. Measuring endocannabinoids in blood can be technically challenging, and although the authors used established analytical methods, they don’t explicitly report whether these methods were validated.”
“I’d also have liked more information about what participants ate during and after exercise,” McCartney added. “We know that nutrient intake can influence blood AEA concentrations, so it’s possible that dietary behavior affected the measures.”
The authors describe their laboratory analysis as following established, standardized protocols, including adding chemically labeled reference versions of each compound to every sample to allow exact measurement. They also acknowledge that participants’ nutrition, rest, and time of day were not fully controlled.
Every participant also ran the marathon before doing the walking session, which the authors note may have raised anxiety at the start of the running day. The samples were also small, with 19 marathoners and between 7 and 16 runners at each ultramarathon distance, and no blood was drawn during the ultramarathons themselves.
The emotional measures relied on brief, single-item rating scales, which capture only a snapshot of complex mental states like flow or emotional relief. Logistics during the ultramarathon also meant that pre-race samples for the 230-kilometer group had to be collected the previous evening rather than right at the starting line.
“One important distinction is that we measured endocannabinoids in the blood, not directly in the brain,” Siebers pointed out. “Although our findings show substantial changes in circulating endocannabinoid concentrations, we cannot yet determine precisely what happens in the brain during prolonged running.”
“Another important point is that the runner’s high is not simply caused by one molecule,” he added. “Endocannabinoids are probably part of a much larger and highly complex orchestra of neuromodulators, including dopamine, serotonin, endogenous opioids, and other signaling systems. Furthermore, not everyone experiences a runner’s high, and running does not necessarily become more enjoyable the longer someone continues.”
When considering future research, McCartney highlighted both pharmacological and nutritional avenues for follow-up testing. “Ideally, I’d like to see whether blocking cannabinoid receptors prevents the runner’s high,” she said. “Unfortunately, the safety concerns associated with drugs like rimonabant make that a difficult experiment to conduct in humans!”
Rimonabant, a drug that blocks the main cannabinoid receptor, was pulled from the European market in 2008 after it was linked to depression and suicidal thoughts.
“More realistically, I’d be interested in seeing whether nutrition influences the endocannabinoid response to prolonged exercise,” McCartney told PsyPost, “particularly given that runners typically consume substantial amounts of carbohydrate during marathon and ultramarathon events.”
Looking ahead, the authors hope to examine how these chemical messengers operate directly within the central nervous system during physical exertion.
“One of my main interests is understanding how running influences mood changes and the brain itself,” Siebers said. “So far, our research has primarily focused on measuring endocannabinoids in peripheral blood. However, the runner’s high ultimately involves processes within the central nervous system, and we still know surprisingly little about what actually happens in the human brain during running. I would therefore like to investigate these central mechanisms more directly, potentially through neuroimaging and other methods that allow us to study neuromodulation in the brain.”
“In addition, I am particularly interested in how the endocannabinoid system interacts with pain regulation during prolonged exercise,” he continued. “Why can some individuals continue running for hours despite considerable physical stress, while others experience increasing discomfort? Understanding these mechanisms could provide valuable insights not only into endurance exercise but also into pain regulation and mental health.”
Beyond laboratory measurements, the researchers also reflected on the broader personal and evolutionary dimensions of sustained running.
Siebers emphasized that the effect requires no outside substance. “What fascinates me is that our bodies can produce their own cannabis-like substances simply through physical activity,” he told PsyPost. “Under the right circumstances, this can contribute to a completely natural high, without consuming any external substance.”
“For me, the most exciting message is that running is much more than moving our legs,” Siebers said. “It is a fascinating interaction between our body and brain, and understanding this interaction may help us discover why humans have developed such an extraordinary relationship with endurance running.”
The study, “Endocannabinoid dynamics across marathon and ultramarathon running: evidence from two field studies,” was authored by Michael Siebers, Dana Huvermann, Christoph Siebers, Deborah Canales-Romero, Alexandra Florea-Ghile, Lina Keite, Lucas John, Moritz Munk, Roman Bizjak, Jens Witzel, Sebastian Schulz, Johannes Kirsten, Laura Bindila, Anke Hinney, Marijke Grau, Daniel A. Bizjak, Harald Engler, and Johannes Fuss.
URL: https://www.psypost.org/your-body-makes-its-own-cannabis-like-chemicals-as-you-run-and-neuroscience-research-finds-they-keep-rising-all-the-way-to-the-marathon-finish-line-a-possible-clue-to-the-runners-high/
-------------------------------------------------
Private, vetted email list for mental health professionals: https://www.clinicians-exchange.org
Unofficial Psychology Today Xitter to toot feed at Psych Today Unofficial Bot @PTUnofficialBot
-------------------------------------------------
#psychology #counseling #socialwork #psychotherapy @psychotherapist @psychotherapists @psychology @socialpsych @socialwork @psychiatry #mentalhealth #psychiatry #healthcare #depression #psychotherapist #RunnersHigh #Running #Marathon #Ultramarathon #EnduranceRunning #SportsScience #Neuroscience #Endocannabinoids #Anandamide #MentalWellness

#psychology #counseling #socialwork #psychotherapy #mentalhealth #psychiatry
Dev Community @[email protected]
2026-10-25
Navigating a restaurant menu can feel overwhelming—especially when you’re balancing taste preferences, dietary goals, and nutritional concerns. With the explosion of AI food tech in recent years, a new era of “smart menu” experiences is emerging. AI menu analysis isn’t just about digitizing paper menus; it’s fundamentally transforming how diners discover, understand, and choose their meals. From estimating hidden calories to surfacing dishes tailored to your preferences, these innovations are reshaping both dining out and online ordering.
The Challenge: Decoding Restaurant Nutrition

Most diners want to make informed choices, but restaurant nutrition information is often buried, incomplete, or absent altogether. Even when calorie counts are available, they rarely account for personal needs—like allergies, macros, or dietary restrictions. Manually scanning for options that fit your criteria can be tedious and error-prone, especially at busy or unfamiliar restaurants.
This is where AI menu analysis comes in. By leveraging machine learning, natural language processing, and computer vision, AI-powered systems can extract, interpret, and enhance menu data at scale. The result: more transparent, personalized, and actionable restaurant nutrition insights for both diners and operators.
How AI Menu Analysis Works
1. Menu Digitization and Parsing

The first step is converting static menus into machine-readable data. AI models (often using OCR—Optical Character Recognition) can scan printed or photographed menus and extract structured information. Natural language processing (NLP) is then applied to parse dish names, descriptions, and even detect ingredient lists.
// Example: Simple menu item extraction using regex and NLP concepts
const menuText = `
Grilled Salmon Salad - Fresh greens, grilled salmon, avocado, and vinaigrette. 450 kcal
Classic Burger - Beef patty, cheddar, lettuce, tomato, brioche bun. 800 kcal
`;
const dishRegex = /(.*?)\s*-\s*(.*?)\.\s*(\d+)\s*kcal/gi;
const menuItems = [];
let match;
while ((match = dishRegex.exec(menuText)) !== null) {
menuItems.push({
name: match[1].trim(),
description: match[2].trim(),
calories: parseInt(match[3], 10)
});
}
console.log(menuItems);
Real-world systems go much further, handling inconsistent formatting, synonyms, and multilingual content.
2. Nutritional Value Estimation

Many menus lack detailed nutrition facts. AI can bridge these gaps by analyzing dish descriptions and predicting nutrition profiles. This typically involves:
Ingredient recognition: Identifying possible ingredients based on dish names and descriptions.
Recipe inference: Estimating likely preparation methods and quantities.
Database matching: Mapping extracted ingredients to known nutrient databases (like USDA or Open Food Facts).
Machine learning models trained on vast recipe and nutrition datasets can predict calories, macros, and even allergen presence with surprising accuracy.
// Pseudo-code: Predicting calories for a dish using AI
async function estimateDishCalories(dishDescription: string): Promise<number> {
// This would call an AI model or API trained on recipe/nutrition data
const estimated = await callCaloriePredictionModel(dishDescription);
return estimated.calories;
}
3. Personalization and Smart Recommendations

AI menu analysis unlocks highly personalized experiences:
Dietary filtering: Instantly flagging dishes that fit vegan, gluten-free, or keto diets.
Allergen detection: Highlighting items that may contain peanuts, shellfish, or other triggers.
Preference learning: Recommending dishes based on past orders, ratings, or explicit preferences.
Health scoring: Ranking menu items by metrics like calorie density, sodium content, or “healthiness” for the user.
Some apps leverage collaborative filtering (like Netflix or Spotify) to surface dishes that similar users have enjoyed. Others use reinforcement learning to improve suggestions over time.
// Example: Filtering menu items for a vegetarian user
const vegetarianKeywords = ['vegetable', 'cheese', 'tofu', 'salad', 'beans'];
function isVegetarian(dish: { description: string }) {
const desc = dish.description.toLowerCase();
return vegetarianKeywords.some(keyword => desc.includes(keyword));
}
const vegetarianOptions = menuItems.filter(isVegetarian);
console.log(vegetarianOptions);
4. Enhanced Menu Interfaces

Modern “smart menu” platforms use AI to power interactive interfaces, both on-premise (via tablets or QR codes) and online. Features include:
Dynamic search: Type “high-protein, under 500 calories” and see instant matches.
Visualizations: See nutrition breakdowns, allergen alerts, or compare dishes side-by-side.
Voice assistants: Ask for “spicy vegan options” and get spoken recommendations.
This not only improves accessibility for all diners, but also helps restaurants stand out in a crowded market.
AI Food Tech in Action

A growing ecosystem of AI food tech products is making these features widely available:
Restaurant apps and POS systems: Many now integrate AI-driven nutrition and filtering.
Third-party platforms: Apps like Yummly, OpenMenu, and LeanDine offer AI-powered menu analysis, personalized recommendations, and nutrition transparency across thousands of restaurants.
Custom deployments: Some restaurant groups build proprietary AI models tailored to their cuisine and customer base.
On the backend, open-source libraries (such as spaCy for NLP, or TensorFlow for custom ML models) enable developers to integrate AI menu analysis into their own applications.
Challenges and Considerations

While the potential is tremendous, deploying AI menu analysis at scale isn’t trivial:
Data quality: Menus are notoriously inconsistent—misspellings, colloquial names, and “secret sauce” ingredients can trip up even the best models.
Cultural and regional variation: Dishes with the same name can differ wildly in composition.
Privacy and consent: Personalization requires collecting user preferences and sometimes health data, raising important privacy questions.
Model transparency: Explaining how calorie or allergen predictions are made is essential for trust and regulatory compliance.
Addressing these challenges requires careful engineering, ongoing model retraining, and clear communication to both restaurants and diners.
Building a Simple AI-Driven Smart Menu (Example)

Suppose you want to provide a “smart menu” experience in your own restaurant web app. At a high level, you’d:
Digitize the menu (via OCR, manual entry, or import).
Parse dish descriptions and structure the data.
Augment with nutrition estimates using an AI API or open database.
Add filtering and ranking based on user dietary preferences.
Display results in a user-friendly, interactive UI.
Here’s a simplified TypeScript-style sketch:
type MenuItem = {
name: string;
description: string;
calories?: number;
isVegan?: boolean;
};
function filterMenu(
items: MenuItem[],
{ maxCalories, veganOnly }: { maxCalories?: number; veganOnly?: boolean }
): MenuItem[] {
return items.filter(item => {
if (maxCalories !== undefined && (item.calories ?? Infinity) > maxCalories) {
return false;
}
if (veganOnly && !item.isVegan) {
return false;
}
return true;
});
}
// Example usage:
const smartMenu = filterMenu(menuItems, { maxCalories: 500, veganOnly: true });
You could further extend this with AI-powered search, nutritional scoring, or even integration with fitness tracking apps.
The Road Ahead

The fusion of AI menu analysis and restaurant nutrition transparency is just beginning. As machine learning models improve and data becomes richer, expect even more granular, actionable insights—like real-time portion customization, automatic pairing suggestions, or even “health nudges” based on your goals.
For both diners and restaurants, smart menus powered by AI food tech are making eating out (and ordering in) a more informed, inclusive, and enjoyable experience.
Key Takeaways

AI menu analysis transforms static restaurant menus into dynamic, personalized, and nutrition-aware experiences.
Restaurant nutrition information is becoming more transparent and actionable through machine learning and NLP.
Smart menu systems enable dietary filtering, allergen detection, and personalized recommendations at scale.
A host of AI food tech solutions—from open-source libraries to commercial platforms—make integration possible for developers and restaurants of all sizes.
Challenges remain around data quality, privacy, and transparency, but the future of AI-powered dining is bright—and getting smarter with every meal.

#ai #healthtech #webdev #tutorial #software #coding #development #engineering #inclusive #community
How AI Is Making Restaurant Menus Easier to Navigate
#ai #community #software #webdev #coding #development
Dev Community @[email protected]
2026-10-25
Most businesses know how to track their Google rankings.
But what happens when a potential customer stops searching on Google and starts asking ChatGPT, Perplexity, or another AI assistant which product they should choose?
Your website might rank well. Your content might get traffic. Your competitors might even have fewer backlinks than you.
Yet when a customer asks an AI assistant for recommendations, your competitors appear while your brand is nowhere to be found.
That creates a new visibility problem: which questions are you losing in AI search?
I'm building Aurvikon to help answer that question.
The problem with measuring AI visibility

Traditional SEO gives us familiar metrics:
Keyword rankings
Impressions and clicks
Organic traffic
Backlinks
Search performance
These metrics remain valuable. But they don't fully explain how your brand appears inside AI-generated answers.
Imagine someone asking an AI assistant:
What are the best tools for improving AI search visibility?
Which platforms help SaaS companies monitor their brand in AI answers?
Compare three alternatives for tracking brand recommendations in AI search.
Which tool should a startup use to understand its visibility in ChatGPT?
Your brand might appear in one answer and disappear from the next.
A competitor might be recommended repeatedly. Another company might be described as the category leader. Your own product might be missing entirely.
Looking at a single AI-generated answer won't tell you the whole story.
You need to understand visibility across the questions your potential customers actually ask.
The shift: from keyword rankings to question-level visibility

I'm interested in a more useful way to think about AI search visibility.
Instead of asking only:
"Does my brand appear in AI search?"
Ask:
"For which relevant buyer questions does my brand appear, where do competitors appear instead, and what can I do about it?"
That second question leads to much more actionable work.
Consider three possible findings from an AI visibility audit:
1. You're missing from important questions.
People ask questions directly related to your product category, but the AI response doesn't mention your company.
2. Your competitors are being recommended instead.
Your product may be relevant, but competing brands are consistently appearing in the answers you're trying to win.
3. Your brand appears, but not in the way you want.
An AI response might mention your company without accurately communicating its core use case, differentiator, or value.
These are different problems. They shouldn't all receive the same recommendation to "publish more content."
What we're building with Aurvikon

Aurvikon is an AI visibility tool focused on helping businesses understand how their brands appear across AI answer platforms.
The core idea is straightforward:
Identify the questions where your brand is losing visibility, understand what appears instead, and turn those findings into an action plan.
A practical workflow looks like this:
Step 1: Identify the questions buyers ask

Start with questions your target customers might ask before choosing a product.
Don't limit the research to your brand name. Include category searches, comparisons, alternatives, use cases, and purchasing decisions.
Step 2: Test those questions across AI platforms

Run relevant questions across the platforms you want to monitor, such as ChatGPT, Perplexity, and Gemini.
Treat the responses as observations to analyze, not as permanent rankings.
Step 3: Identify where you're losing

Look for patterns:
Which questions mention your brand?
Which questions mention competitors but not you?
Where are you missing from relevant comparisons?
Which product capabilities or use cases aren't being communicated?
Which questions deserve attention first?
This is where an audit becomes more useful than a collection of screenshots.
Step 4: Turn findings into actions

Every visibility gap should lead to a hypothesis.
Maybe a product page doesn't explain a use case clearly. Maybe your comparison content is weak. Maybe your product lacks supporting content for a particular buyer question.
Investigate the evidence, make the relevant improvement, and test again.
The goal isn't to manufacture mentions. It's to make your brand easier to understand, evaluate, and recommend when it genuinely fits the user's needs.
The difficult part isn't generating an AI visibility report

AI answers change. Results can vary by wording, location, model version, and time.
That means a report saying "your brand was mentioned" is only a starting point.
A useful system should help you move from observation to diagnosis:
Buyer question → AI response → competitor comparison → visibility gap → action → retest.
That repeatable workflow is the problem space we're focused on at Aurvikon.
We're especially interested in making the results useful to founders and marketing teams who need to decide what to fix next, rather than simply collecting another dashboard of numbers.
What this means for SaaS founders

If you're building a SaaS company, think about the questions someone would ask immediately before buying your product.
Not just:
"What is [your brand]?"
But:
What is the best alternative to [competitor]?
Which tools solve [specific customer problem]?
Compare products that offer [important capability].
What should a small business use for [desired outcome]?
Which platform is best for [specific use case]?
These questions reveal how AI assistants represent your category and which products they surface for potential buyers.
They can also reveal gaps in your positioning and content strategy.
AI visibility isn't a replacement for SEO. It's an additional area to measure as customers discover products through AI-generated answers.
I'm building Aurvikon around one practical question

I believe the most useful starting point for AI visibility isn't another generic score.
It's knowing which valuable questions your company is losing, which competitors show up instead, and what you should investigate next.
That's the problem we're working on with Aurvikon.
I'd love to hear from other founders, SEO professionals, and SaaS marketers:
If you could see every important buyer question where AI assistants recommend your competitors instead of you, what would you want the tool to tell you first?
Would you prioritize the competing brands, the missing content, the sources behind the answers, or the specific actions most likely to improve visibility?
I'm interested in how people are approaching this problem in practice.#ai #seo #startup #showdev #software #coding #development #engineering #inclusive #community
Your Brand Can Rank on Google and Still Be Invisible in AI Search
#ai #community #software #coding #development #engineering
Blogger-Network-Theo-Herbots @[email protected]
2026-10-25
🎄✨ Feestelijk Kerstmenu 2026: ✨🎄||🎄✨ Festive Christmas Menu 2026: ✨🎄

Begin op Tijd met de Voorbereidingen! ✨🎄
🎅 Een woordje vooraf van Theo-Herbots, keukenpiet in Tienen
A warmly lit Christmas dining table welcomes guests with roast turkey, candlelight, and seasonal greenery.
Misschien lijkt het wat vroeg om nu al een kerstmenu samen te stellen. Toch zegt een oude wijsheid: beter te vroeg dan te laat! Door nu al na te denken over uw feestmenu kunt u rustig ingrediënten verzamelen, recepten uitproberen en stress tijdens de eindejaarsperiode vermijden.
Daarom stel ik u vandaag een volledig kerstmenu voor, van aperitief tot dessert, inclusief dranken, werkwijzen en enkele gezellige tips om van Kerstmis een onvergetelijke familieavond te maken.

🥂 Aperitiefhapjes: Feestelijk Beginnen
🧀 Kaaskrokantjes met vijgenconfituur
Crisp herb crackers, fig jam, fresh figs, and white wine create an inviting rustic appetizer spread.
Ingrediënten
12 plakjes bladerdeeg
100 g geitenkaas
Vijgenconfituur
1 ei
Werkwijze
Snijd kleine vierkantjes uit het bladerdeeg.
Leg een stukje geitenkaas en een beetje confituur in het midden.
Vouw dicht en bestrijk met losgeklopt ei.
Bak 15 minuten op 180°C.
🍷 Bijhorende drank
Cava Brut
Prosecco
Alcoholvrije mousserende wijn

🍤 Voorgerecht: Garnalencocktail Deluxe
A beautifully layered shrimp cocktail takes center stage at an intimate candlelit dinner table.
Ingrediënten
400 g grijze garnalen
Gemengde sla
Komkommer
Tomaat
Cocktailsaus
Citroen
Werkwijze
Verdeel de sla over glazen of coupes.
Werk af met komkommer en tomaat.
Voeg de garnalen toe.
Werk af met cocktailsaus en een schijfje citroen.
🍷 Bijhorende drank
Droge witte wijn
Pinot Grigio
Frisse witte Bourgogne

🐟 Tussengerecht: Romige Vissoep
A creamy seafood chowder, fresh bread, and white wine create a warm, inviting dining scene.
Ingrediënten
500 g visafval of visbouillon
1 prei
1 wortel
1 ui
200 ml room
Peper en zout
Werkwijze
Stoof de groenten aan.
Voeg visbouillon toe.
Laat 30 minuten zacht koken.
Mix en werk af met room.
🍷 Bijhorende drank
Chardonnay
Licht houtgerijpte witte wijn

🦃 Hoofdgerecht: Kalkoenfilet met Kroketten en Wintergroenten
Sliced roast pork, crispy croquettes, and roasted vegetables create a festive dinner spread.
Ingrediënten
Voor de kalkoen
1,5 kg kalkoenfilet
Boter
Tijm
Rozemarijn
Peper en zout
Voor de groenten
Wortelen
Spruitjes
Pastinaak
Honing
Voor het garnituur
Aardappelkroketten
Werkwijze
Kruid de kalkoen royaal.
Bak rondom goudbruin.
Laat verder garen in de oven op 180°C.
Rooster de wintergroenten met een beetje honing.
Bak de kroketten goudbruin.
🍷 Bijhorende dranken
Rode Bordeaux
Merlot
Belgische kerstbieren voor de bierliefhebbers

🍰 Nagerecht: Feestelijke Speculoosmousse
A layered holiday dessert takes center stage beside a glowing Christmas tree and candle.
Ingrediënten
250 ml slagroom
150 g mascarpone
100 g speculooskoekjes
2 eetlepels speculoospasta
Werkwijze
Klop de room stevig op.
Meng mascarpone en speculoospasta.
Spatel de room eronder.
Verkruimel de koekjes.
Maak laagjes in mooie glazen.
Laat minstens 2 uur opstijven.
☕ Bijhorende drank
Koffie
Cappuccino
Dessertwijn
Irish Coffee voor de liefhebbers

🎄 Gezellige Kersttips voor een Warme Sfeer
A woman decorates by the Christmas tree while a dog rests beside the glowing fireplace.
🕯️ Zorg voor sfeervolle verlichting
Gebruik kaarsen, kerstlichtjes en een mooi gedekte tafel. Warm licht zorgt onmiddellijk voor gezelligheid.
🎶 Kies rustige achtergrondmuziek
Klassieke kerstliedjes of zachte jazzmuziek creëren een ontspannen sfeer zonder storend te zijn.
👨‍👩‍👧‍👦 Geniet van elkaars gezelschap
Leg smartphones even opzij en maak tijd voor gesprekken, herinneringen en leuke verhalen.
🎁 Voorzie een kleine verrassing
Een persoonlijk kaartje of klein attentie aan tafel wordt altijd gewaardeerd.
📸 Maak herinneringen
Vergeet niet enkele foto’s te nemen zodat u later nog eens kunt terugblikken op een gezellige kerstavond.

🎅✨ Slotwoord van Theo-Herbots, keukenpiet in Tienen
A cozy farmhouse kitchen celebrates the holidays with stew, vegetables, cookies, and warmly spiced drinks.
Kerstmis draait niet alleen om lekker eten, maar vooral om samen zijn met familie en vrienden. Met een goede voorbereiding kunt u volop genieten van de feestdagen zonder stress in de keuken. Daarom is het helemaal niet te vroeg om nu al ideeën op te doen voor uw kerstmenu.
Ik wens u alvast veel plezier bij de voorbereidingen en vooral een warme, gezellige en smakelijke kerstperiode toe. Want de mooiste ingrediënten van een geslaagde kerst zijn nog altijd liefde, vriendschap en gezelligheid rond de feesttafel.
Smakelijke feestdagen en gezellige groeten uit Tienen! 🎄🍷✨
Theo Herbots, keukenpiet in Tienen 👨‍🍳🎅📸
🎄 Vind jij dit kerstrecept lekker?
Heeft dit heerlijke kerstrecept je geïnspireerd? 😍✨
📢 Deel de kerstsfeer verder
Deel dit recept gerust met je familie, vrienden en kennissen. Zo kunnen ook zij genieten van deze feestelijke lekkernij tijdens de mooiste tijd van het jaar. 🎅🍽️
❤️ Samen genieten smaakt beter
Ken je iemand die graag kookt of op zoek is naar inspiratie voor het kerstmenu? Stuur dit recept dan zeker door. Misschien delen zij het op hun beurt weer met hun familie en vrienden. 🤝🎄
🌟 Hoe meer mensen, hoe meer kerstplezier
Laten we samen zoveel mogelijk mensen laten genieten van deze heerlijke kerstgerechten. Bekijk ook mijn andere feestelijke recepten, tips en inspiratie voor een onvergetelijke kerst. ✨🍷🍰
🎁 Bedankt voor je steun
Dankjewel voor het lezen, delen en steunen van mijn blog. Samen maken we van Kerstmis een warm, gezellig en smakelijk feest voor iedereen! 🎄❤️😊
#Kerstmis, #Kerstmenu, #Kerstrecepten, #Feestdagen, #SamenGenieten, #TheoHerbots #Tienen 🎅✨🍽️🎄🎁,
☕ Sluit het gezellige samenzijn in stijl af met een heerlijke kop Gourmet Black Coffee van Organo Gold.
Geniet nog even na van alle mooie momenten, terwijl de rijke smaak en het verfijnde aroma zorgen voor een warme en smaakvolle afsluiter. ✨
Ervaar de geur van vers gezette koffie in een handomdraai met ORGANO Gourmet Zwarte koffie. Kenners zullen de robuuste, zachte smaak, die wordt versterkt met een rijke Ganoderma lucidum waarderen. Wek je zintuigen en verrijk uw dag met een klassieke kop koffie die net zo smaakvol als verkwikkend is.
Gourmet Black Coffee – Organo Gold

Hier beneden kom je terecht op een plek waar mijn levenswerk samenkomt. Druk je erop, dan zie je eerst een warme inleiding tot die categorie… en daarna alle blogberichten die ik in die rubriek met liefde, tijd en ziel heb opgebouwd.
Het is meer dan een menu. Het is een reis door mijn verhalen, mijn foto’s, mijn herinneringen, mijn inzichten — alles wat ik door de jaren heen heb gedeeld met wie hier graag vertoeft.
Breng een Bezoek KLIK ➡️HIER ✅👍
💌 Blijf Verbonden — Volg Onze Nieuwsbrief
A smiling woman works on a laptop while inviting viewers to follow the newsletter from a cozy café.
Theo‑Herbots dankt u uit de grond van zijn hart voor uw inschrijving.
Echt waar… dit betekent meer dan zomaar een naam op een lijst. Het betekent vertrouwen. Verbondenheid. Een stukje warmte dat jij met ons wil delen.
En geloof me… je zal er geen spijt van krijgen. Elke nieuwsbrief wordt met zorg, liefde en een vleugje Tiense ziel samengesteld — alsof ik hem persoonlijk bij jou in de brievenbus kom steken 💌✨
Vergeet niet om na je inschrijving even in je inbox te kijken. Klik daar op de bevestigingslink, zodat je inschrijving helemaal in orde is. Deze extra stap is speciaal ingebouwd om jou te beschermen tegen spam 💛✨
📬 Tip: Kijk ook even in je spambox, soms verstopt het mailtje zich daar.
Met jouw inschrijving geef je jezelf een klein cadeautje: een moment van verbinding, verhalen, foto’s, nostalgie en groeten uit Tienen die je hart raken. Elke nieuwsbrief is een beetje alsof we samen aan tafel zitten met een tas koffie ☕💛 — warm, eerlijk, menselijk.
Wil je niets missen van onze verhalen, foto’s, inzichten en warme momenten? Schrijf je dan in op onze nieuwsbrief en ontvang regelmatig een vleugje inspiratie, een glimlach, een gedachte om mee te nemen… recht uit Tienen, recht uit ons hart. 💙✨
Elke nieuwsbrief is een klein cadeautje:
📸 een foto die raakt
✍️ een tekst die blijft hangen
🌿 een tip die je dag lichter maakt
🤝 een gevoel van verbondenheid
Word deel van onze groeiende community. Samen maken we het mooier.
Vergeet niet om na je aanmelding je mail-box te checken en op die bevestigingslink te klikken. Dit is een slimme zet om jou te beschermen tegen die vervelende Spam.
We zijn net zo anti-Spam als jij! En maak je geen zorgen, jouw gegevens worden “NIET” gedeeld met anderen!
Voeg je bij 33K andere abonnees
Dankjewel aan iedereen die de tijd neemt om ons te laten weten dat ons werk hen raakt. Dankjewel voor de warmte, de steun en de verbondenheid. Dankjewel dat jullie onze blog niet alleen lezen, maar ook mee vormgeven door jullie reacties.
Samen maken we van deze plek een hartelijke, eerlijke en inspirerende online thuis. En dat is misschien wel het mooiste compliment dat we kunnen krijgen.
Warme groet uit Tienen, Theo‑Herbots 💙📚 Blogger met Hart & Ziel
P.S. Nu u toch hier bent…
💬 Laat gerust een reactie achter onderaan dit bericht. Ik lees graag uw mening, ervaringen of aanvullingen.
🌐 Neem ook eens een kijkje op mijn sociale media via de links hieronder. Daar deel ik regelmatig nieuwe inzichten, tips, handelsideeën en updates.
🔄 Vond u dit bericht nuttig of interessant? Help dan mee om deze informatie te verspreiden en deel het verder via de sociale media-deelknoppen onderaan deze pagina.
🙏 Alvast bedankt voor uw bezoek, uw reactie en het delen. Samen bereiken we meer mensen die er hun voordeel mee kunnen doen!
✨ Veel leesplezier en graag tot binnenkort! 🚀
📱 Goed nieuws! Vanaf nu zijn wij ook bereikbaar via WhatsApp. 🎉
Heb je een vraag over mijn blog, een blogbericht of één van de diensten die ik aanbied? Dan mag je mij gerust een WhatsApp-bericht sturen. 😊
⚠️ Belangrijk: dit WhatsApp-kanaal is uitsluitend bedoeld voor vragen over mijn blog en mijn diensten. Reclameboodschappen, commerciële aanbiedingen en spamberichten worden niet beantwoord.
💬 Ik help je graag verder met al je vragen!
Chat op WhatsApp
Theo Herbots
🌟📸 Blogger & Fotograaf uit Tienen 💙
Volg ons ook op Social-Media hier beneden👇
A cheerful creator invites viewers to follow, like, and share content in Dutch. Follow us on Social Media xfacebookinstagramyoutubepinterestlinkedinflickrtumblrvimeofoursquaremastodon #KerstmisKerstmenuKerstreceptenFeestdagenSamenGenietenTheoHerbotsTienen #TheoHerbots #TheoHerbotsFotografie #KerstmisChristmas #StepByStepChristmasMenu #TheoHerbotsTheVoiceFromTienen
#kerstmiskerstmenukerstreceptenfeestdagensamengenietentheoherbotstienen #theoherbots #theoherbotsfotografie #kerstmischristmas #stepbystepchristmasmenu #theoherbotsthevoicefromtienen
WDR (inoffiziell) @[email protected]
2026-10-25

Drei Schiffe, 125 Reisen, 20.000 Gäste: Duisburg wird ab 2027 zum neuen Startpunkt für Flusskreuzfahrten.#WDR #Duisburg #Flusskreuzfahrt #Kreuzfahrt #A-Rosa #Rhein #Tourismus #Urlaub #Amsterdam #Rotterdam #IGA2027 #Starthafen #Schiffe #Antwerpen #Gent #Mosel #Donau #Nijmegen #Emmerich #Republishing #NRW
20.000 Gäste pro Jahr: Duisburg wird Startpunkt für Flusskreuzfahrten

#tourismus #urlaub #nrw #duisburg #wdr #emmerich
arosano 🇩🇰 🇮🇱 @[email protected]
2026-10-26

With all the current hype about #netbsd it will take 2nd spot from #openbsd one of these days. Then I might like that better. The #underdog you know.

#netbsd #openbsd #underdog
arotrios @[email protected]
2026-10-25

Watch Rome Rise, Fall, and Rise Again in a Three-Minute 3D Timelapse
Watch Rome Rise, Fall, and Rise Again in a Three-Minute 3D... #history #rome
https://kbin.earth/m/[email protected]ld/t/3320476

#rome #history