Heiswayi Nrird

archmap

Wed, 17 Jun 2026 24:00:00 GMT

I wanted a map before reading the code

When I open an unfamiliar project, I do not want to start with every file equally important.

I want the first map.

Where are the entry points? Where are the models? Which files are only configuration? Which modules depend on which other modules? Is this a small tool with a clean shape, or a folder full of hidden complexity?

You can discover all of that manually, but it takes time. You open the tree, jump between imports, read filenames, follow conventions, and slowly build a mental model in your head.

That mental model is useful, but it is also temporary. It stays with the person who did the reading. It gets stale when the project changes. And it is rarely written down unless somebody has the patience to draw a diagram.

So I built archmap, a new open source project for briefly reviewing any app architecture and making the result presentable as a single self-contained HTML file.

What it does

archmap scans a project folder, builds a quick architecture overview, and generates one standalone interactive HTML file.

No server.

No database.

No external assets.

No runtime dependencies.

Just run:

archmap /path/to/project

Then open the generated *-architecture.html file in a browser.

The report gives you a few useful views:

an overview of files, lines, languages, classes, functions, and dependency edges
inferred architecture layers such as entry points, config, models, API, services, data access, integrations, UI, utilities, tests, docs, and build/ops
internal dependency links between project files
a collapsible file tree
a searchable component reference
a side panel for each file with its imports, classes, functions, methods, and links to related files

The important part is that everything is embedded in a single HTML file. The project data is serialized as JSON inside the page, so the report is easy to share, archive, or attach to documentation.

The architecture is deliberately boring

The tool itself is pure Python.

That choice matters. I wanted it to be easy to install, easy to run, and easy to package as a standalone binary later. A tool like this should not ask for much before it gives you value.

The pipeline is simple:

scan the project tree
analyze each source file
classify files into architecture layers
resolve internal dependencies
render the result into HTML

The scanner skips the usual noise: .git, node_modules, build folders, virtual environments, caches, binary assets, lockfiles, and files larger than about 2 MB. It also honors .gitignore by default.

Python files get deeper analysis through the standard library ast module. That means classes, functions, methods, imports, and module docstrings can be extracted more reliably.

Other languages use lightweight heuristics. That is not perfect, but it is practical. The goal is not to become a compiler for every language. The goal is to produce a useful architecture map quickly.

Layer detection is heuristic, but useful

Architecture is often visible in names.

A file under src/api/routes.js probably belongs to an API layer. A file under models/ is probably a data model. A Dockerfile, pyproject.toml, or GitHub Actions workflow belongs closer to build and operations. A file named cli.py or main.go is likely an entry point.

archmap uses those signals to classify files into layers.

It looks at directory names, filename hints, and extensions. Directory names carry the strongest signal. Filename hints come next. Extensions are a weaker fallback.

This is not a formal architecture rule system. It is a first-pass classifier.

That is enough for the intended use case. When you are trying to understand a project quickly, a good approximation is much better than a blank page.

Dependency links make the map more useful

A file tree tells you where things live.

A dependency graph tells you how things relate.

archmap tries to resolve imports between files in the same project. For Python, it handles dotted imports and relative imports. For JavaScript and similar languages, it handles path-style imports where possible.

The report then shows both directions:

what this file depends on
what uses this file

That second direction is often the more useful one. When you are thinking about changing a file, you usually want to know who will be affected.

It is not trying to replace deeper tools

There are limits.

archmap is not a full static analyzer. It does not understand every framework. It does not evaluate dynamic imports. It does not know your domain architecture. It cannot tell whether your layering is correct.

And for non-Python languages, the extraction is intentionally heuristic.

That is fine.

I see this as a fast orientation tool, not a formal verification tool. It gives you enough structure to start reading with better context.

The difference is similar to looking at a city map before walking through the streets. The map will not show every detail, but it prevents you from wandering blindly.

Why a single HTML file

I like tools that leave behind simple artifacts.

A standalone HTML file is boring in the best way. You can open it locally. You can send it to someone. You can keep it next to release notes. You can regenerate it whenever the project changes.

There is no service to run and no account to create.

That also makes it useful in environments where source code cannot leave the machine. You can generate the report locally and keep it local.

Installation

The package is published as archmap-cli and provides the archmap command.

With pipx:

pipx install archmap-cli

Or with pip:

pip install archmap-cli

Then:

archmap .

A few useful options:

# scan a specific project
archmap /path/to/project

# write to a custom output file
archmap /path/to/project -o architecture.html

# set the display name
archmap /path/to/project --name "My Service"

# open the generated report after building it
archmap /path/to/project --open

# ignore .gitignore rules
archmap /path/to/project --no-gitignore

What I like about this kind of tool

It does not ask you to change your workflow.

It does not require you to annotate your code.

It does not need a configuration file before it can do something useful.

You point it at a folder and it gives you a map.

That is enough for many moments: onboarding, refactoring, reviewing a small service, auditing an old project, or handing work to another developer.

A map does not have to be perfect to be helpful.

It only has to make the next step clearer.

Closing thought

Most developers eventually build a private map of every project they touch.

archmap turns part of that private map into a real artifact.

Not the final truth of the codebase. Not complete documentation. Not architecture governance.

Just a useful first look.

And sometimes that is exactly what you need before making good decisions.

Building stdnotes.app

Sat, 23 May 2026 24:00:00 GMT

I wanted a note-taking app that did one thing well: let me write immediately, without forcing me to create an account, pick a pricing plan, or wait for a server to respond. Everything else - cloud sync, sharing, billing - would be optional layered on top.

This post covers the architectural decisions behind stdnotes: why I chose each piece of the stack, how the offline-first design works at the implementation level, and what I'd do differently next time.

The Problem I Was Solving

Most note apps are cloud-first. Your notes don't exist until they're on a server. If you're on a plane, in a basement, or behind a corporate proxy, you're blocked. And every one of them requires an account before you can type a single character.

I wanted to flip this: start offline by default, opt into the cloud later. The mental model is simple:

Open the app → write immediately
Notes live in IndexedDB (your browser's built-in database)
Sign in with Google whenever you want → notes sync to Firestore
Never signed in? Your notes are still there, every time you open the app

This sounds obvious, but it has real architectural consequences that ripple through the entire codebase.

Architecture Overview

flowchart LR
    user((User))

    frontend["Frontend<br/>Next.js"]
    indexeddb[("IndexedDB<br/>Offline Store")]
    backend["Backend API<br/>Fastify"]
    firestore[("Firestore<br/>Cloud Database")]
    auth["Firebase Auth<br/>Authentication Service"]

    user --> frontend

    frontend <-->|HTTP / REST| backend
    frontend <-->|WebSocket<br/>Live Sync| backend

    frontend <-->|Read / Write<br/>Offline Cache| indexeddb

    backend <-->|Read / Write| firestore
    frontend -->|Sign in / Session| auth
    backend -->|Verify Auth Token| auth

    classDef app fill:#eef6ff,stroke:#2563eb,stroke-width:1.5px,color:#111827;
    classDef db fill:#f0fdf4,stroke:#16a34a,stroke-width:1.5px,color:#111827;
    classDef service fill:#fff7ed,stroke:#ea580c,stroke-width:1.5px,color:#111827;
    classDef user fill:#f5f3ff,stroke:#7c3aed,stroke-width:1.5px,color:#111827;

    class frontend,backend app;
    class indexeddb,firestore db;
    class auth service;
    class user user;

The stack is a TypeScript monorepo with three workspaces:

stdnotes/
├── frontend/   → Next.js 15 + React 19
├── backend/    → Fastify 5 + firebase-admin
└── packages/shared/  → shared TypeScript types, constants

The key architectural constraint: the frontend never talks to Firestore directly. There is no Firestore client SDK in the browser. All database operations go through the Fastify backend, which uses the Firebase Admin SDK. This keeps auth enforcement in one place, prevents client-side rule bypasses, and makes the frontend portable to any database backend.

The Dual Storage Backend

The offline-first requirement forced me to design a clean abstraction for storage operations early on. I ended up with a Backend interface that both the online and offline implementations satisfy:

interface Backend {
  createNote(note: Partial<Note>): Promise<Note>;
  updateNote(id: string, patch: Partial<Note>): Promise<void>;
  deleteNote(id: string): Promise<void>;
  subscribeNotes(cb: (notes: NoteMeta[]) => void): Unsubscribe;
  // ... folders, settings, etc.
}

Offline backend (createOfflineBackend): reads and writes to IndexedDB via the idb library. Subscriptions use a local pub-sub emitter - when you create a note, subscribers are notified synchronously.

Online backend (createOnlineBackend): sends HTTP requests to the Fastify API and subscribes to real-time updates via WebSocket streams.

The workspace context picks which implementation to use based on auth state. React components never know which backend is active - they just call backend.createNote() and it works in both modes.

// Inside workspace-context.tsx
const backend = user
  ? createOnlineBackend(apiClient, authToken)
  : createOfflineBackend(idbStore);

This design means switching from offline to online mode is a context update, not a data migration. The note list re-renders with cloud data; local IndexedDB data is preserved for manual migration later.

Content Compression with lz-string

Storing thousands of notes in IndexedDB (and later in Firestore) made me think about size. A rich-text note with some formatting can easily be 5–15 KB of HTML. Over 1,000 notes, that's 5–15 MB in the browser's storage quota.

I chose lz-string for UTF-16 compression. The key reason over alternatives: it produces a regular JavaScript string (no binary blobs), which works seamlessly in both IndexedDB and Firestore without any special serialization.

The compression is applied transparently on write:

function compress(content: string): string {
  if (content.length < 64) return content; // not worth compressing short strings
  const compressed = LZString.compressToUTF16(content);
  return 'lz1:' + compressed; // prefix identifies compressed strings
}

function decompress(stored: string): string {
  if (!stored.startsWith('lz1:')) return stored;
  return LZString.decompressFromUTF16(stored.slice(4)) ?? stored;
}

Typical results: ~60–70% size reduction on rich-text HTML, ~50% on Markdown. The backend never decompresses content - it treats it as an opaque string and passes it through. Decompression happens only in the browser.

Real-Time Sync via WebSocket Streams

Once a user signs in, their notes need to update in real time across devices. I chose WebSockets over polling for the obvious latency reasons, but the implementation has some interesting details.

The backend exposes stream endpoints like /stream/notes and /stream/folders. Each sends an initial snapshot event with all current data, then added, modified, and removed events as Firestore changes come in:

// backend: routes/stream/notes.ts
fastify.get('/stream/notes', { websocket: true }, async (socket, request) => {
  const uid = await verifyToken(request);
  const heartbeat = setInterval(() => socket.send(JSON.stringify({ type: 'ping' })), 25000);

  const unsubscribe = db.collection(`users/${uid}/notes`)
    .onSnapshot(snapshot => {
      // send initial snapshot
      if (snapshot.metadata.fromCache === false) {
        socket.send(JSON.stringify({ type: 'snapshot', data: snapshot.docs.map(toNote) }));
      }
      // then send incremental changes
      snapshot.docChanges().forEach(change => {
        socket.send(JSON.stringify({ type: change.type, data: toNote(change.doc) }));
      });
    });

  socket.on('close', () => { clearInterval(heartbeat); unsubscribe(); });
});

The frontend reconnects automatically with exponential backoff on disconnect. The 25-second heartbeat prevents proxy timeouts (most proxies close WebSocket connections idle for >30 seconds).

Three Editors, One Storage Format

Notes have a contentType field: richtext, markdown, or canvas. The storage layer doesn't care - content is always a compressed string. The editors handle their own serialization.

Rich Text: TipTap

TipTap wraps ProseMirror with a React-friendly API and a rich extension system. I chose it over Lexical because the extension ecosystem is more mature (tables, task lists, code blocks with syntax highlighting all work out of the box).

Content is stored as HTML. The tricky part: TipTap's HTML isn't always round-trippable to Markdown, so exports use Turndown with custom rules for task lists and tables.

Markdown: CodeMirror 6

CodeMirror 6 is the right choice for a Markdown editor because it's lightweight, extensible, and has first-class syntax highlighting via @codemirror/lang-markdown. I added a toggle between edit mode and a rendered preview (via react-markdown + rehype-sanitize for XSS protection).

// The preview uses rehype-sanitize to strip script tags and event handlers
<ReactMarkdown
  remarkPlugins={[remarkGfm]}
  rehypePlugins={[rehypeSanitize]}
>
  {note.content}
</ReactMarkdown>

Canvas: Excalidraw

Excalidraw is essentially a full drawing application you can embed in a React component. Canvas notes store JSON ({ elements, appState, files }) as their content - same compression pipeline as the other content types.

One useful feature: canvas drawings can be inserted as images into rich-text notes. Excalidraw exports SVG/PNG via its built-in API, and TipTap's image extension handles the insertion.

Wiki-Links and the Knowledge Graph

The [[Note Title]] syntax is implemented as a custom TipTap node (for rich text) and a CodeMirror decoration (for Markdown). An alias form [[Title|display text]] lets you show custom link text without changing the target. When you type [[, a typeahead popup appears with matching note titles.

The knowledge graph at /graph is a force-directed SVG layout built without an external graph library. Each note is a node; each [[link]] creates an edge. I computed the layout with a basic force simulation (attraction along edges, repulsion between all nodes, damping):

function simulateStep(nodes: GraphNode[], edges: GraphEdge[]) {
  // repulsion: push all nodes apart
  for (let i = 0; i < nodes.length; i++) {
    for (let j = i + 1; j < nodes.length; j++) {
      const dx = nodes[j].x - nodes[i].x;
      const dy = nodes[j].y - nodes[i].y;
      const dist = Math.sqrt(dx * dx + dy * dy) || 1;
      const force = REPULSION / (dist * dist);
      nodes[i].vx -= (dx / dist) * force;
      nodes[j].vx += (dx / dist) * force;
      // ...
    }
  }
  // attraction: pull linked nodes together
  edges.forEach(edge => {
    // spring force along each edge
  });
  // apply velocity with damping
  nodes.forEach(n => { n.x += n.vx * 0.8; n.vx *= 0.9; });
}

Avoiding a third-party library kept the bundle small and gave me full control over the visual style.

Version History

Version snapshots are stored in a Firestore subcollection: users/{uid}/notes/{id}/versions. A new version is captured when:

The note content changes by more than 500 characters, and
At least 5 minutes have passed since the last snapshot

This throttling prevents a snapshot on every keystroke while still capturing meaningful checkpoints. A FIFO eviction policy keeps at most 20 versions per note - when a 21st version is written, the oldest is deleted in the same Firestore transaction.

async function maybeCreateVersion(uid: string, noteId: string, note: Note) {
  const versions = await getVersions(uid, noteId);
  const latest = versions[0];
  const deltaChars = Math.abs(note.content.length - (latest?.content.length ?? 0));
  const minutesSince = latest ? (Date.now() - latest.savedAt.toMillis()) / 60000 : Infinity;

  if (deltaChars < 500 && minutesSince < 5) return;

  const batch = db.batch();
  batch.set(versionRef, { ...note, savedAt: Timestamp.now() });
  if (versions.length >= 20) {
    batch.delete(versions[versions.length - 1].ref);
  }
  await batch.commit();
}

Public Sharing and Vanity URLs

Any note can be made publicly readable via a toggle. Sharing options include password protection, link expiry (24h / 7d / 30d / never), and a custom vanity slug. The sharing state is stored on the note document (shared: true) and enforced in Firestore security rules - unauthenticated requests can read a note only if shared == true and the share hasn't expired.

Vanity slugs (/s/my-custom-slug) are stored in a separate top-level Firestore collection (share_slugs/{slug}) mapping to (uid, noteId). The backend resolves the slug and returns the note in a single request.

// Firestore security rule for public note access
match /users/{uid}/notes/{noteId} {
  allow get: if resource.data.shared == true
             && (!('shareConfig' in resource.data)
                 || !('expiresAt' in resource.data.shareConfig)
                 || resource.data.shareConfig.expiresAt == null
                 || resource.data.shareConfig.expiresAt > request.time.toMillis());
}

Workspace Export as a Background Job

Exporting an entire workspace (potentially thousands of notes) can take minutes. Blocking the HTTP request isn't an option. Instead:

Frontend calls POST /exports → backend creates an export_job document in Firestore with status queued
A separate export worker process polls Firestore for queued jobs
Worker decompresses each note, converts to Markdown/HTML, bundles as a ZIP
ZIP is uploaded to Cloud Storage; a signed download URL is written back to the job document
Frontend streams progress via the /stream/exports WebSocket endpoint

Frontend → POST /exports → Firestore: export_job (queued)
                                          ↑ polls
                                     Export Worker → ZIP → Cloud Storage
                                          ↓ writes downloadUrl
Frontend ← WebSocket stream ← Firestore: export_job (done, downloadUrl)

The worker runs as a separate Node process. This keeps the Fastify API stateless and prevents long-running jobs from blocking the event loop.

Billing: Two Payment Providers

I integrated both Stripe and Lemon Squeezy as payment options. The subscription state is normalized into a single subscription object on the user document, regardless of provider:

interface Subscription {
  plan: 'free' | 'pro';
  status: 'active' | 'trialing' | 'past_due' | 'canceled';
  provider: 'stripe' | 'lemonsqueezy' | null;
  customerId: string | null;
  subscriptionId: string | null;
  currentPeriodEnd: number | null;
  cancelAtPeriodEnd: boolean;
}

Webhook handlers for both providers normalize their payloads into this shape and write it to Firestore. Idempotency is enforced via stripe_events and ls_events collections - before processing any webhook, the handler checks if the event ID has already been processed.

Having two providers adds maintenance surface area, but it gives payment method flexibility without rewriting the frontend or data model.

Update (v7.0.0): The Pro plan was removed and all features - version history, image uploads, sharing, workspace export, cloud sync - are now free. The billing infrastructure (webhook handlers, Firestore subscription documents) is retained in the backend but no checkout or upgrade UI is exposed to users.

Design Decisions I'd Revisit

Firestore as the backend database: Firestore's real-time capabilities are excellent, but the cost model and the lack of arbitrary server-side queries (no JOIN, limited aggregation) can be constraining. For a future version, I'd evaluate PocketBase or a Postgres-backed alternative.

No end-to-end encryption: Notes are encrypted at rest by Firestore, but Firestore can read them. For a truly private note app, client-side encryption (encrypting before sending to the backend) would be necessary. This is a significant architectural addition - key management, no server-side search - but it's the right answer for users who care about privacy.

Rich text stored as HTML: HTML is flexible but brittle for round-tripping. A structured document format (ProseMirror JSON, or similar) would be a more reliable base for export and transformation.

No real-time collaboration: The current model is last-writer-wins. Two devices editing the same note simultaneously will lose one version. CRDT-based merging (e.g. Yjs) would solve this, at significant complexity cost.

What I Learned

The biggest lesson: the offline-first constraint was a forcing function for good architecture. Because I had to design a storage abstraction from day one, the codebase ended up with clean separation between UI, state, and storage. The dual backend design made testing easier and the app more resilient.

The content compression was a late addition, but it turned out to be more impactful than expected - not just for storage, but for WebSocket message size and Firestore document read costs.

Finally, building a note app from scratch gave me deep appreciation for how much invisible complexity lives in "just a text editor". Autosave with debounce, cursor position preservation across content updates, Markdown shortcut detection, image paste handling - these are each their own small rabbit holes.

Stack Summary

Layer	Technology	Why
Frontend	Next.js 15 + React 19	App Router, SSR, mature ecosystem
Backend	Fastify 5	Fast, TypeScript-native, great plugin system
Database	Cloud Firestore	Real-time subscriptions, managed scaling
Storage	Cloud Storage	Images, export ZIPs
Auth	Firebase Auth	Google sign-in, ID token validation
Rich text editor	TipTap (ProseMirror)	Best-in-class React integration, extension ecosystem
Markdown editor	CodeMirror 6	Syntax highlighting, lightweight, extensible
Canvas editor	Excalidraw	Complete drawing app, active community
Offline storage	IndexedDB (idb)	Browser-native, no quota surprises
Compression	lz-string	UTF-16 strings, works in IndexedDB + Firestore
Styling	Tailwind CSS	Utility-first, flat design system
Shared types	TypeScript monorepo	Single source of truth for Note, Folder, etc.
Billing	Stripe + Lemon Squeezy	Provider flexibility (webhook infra retained; Pro plan removed in v7)

If you're building something similar - an offline-first app with optional cloud sync - the dual backend abstraction is the pattern I'd reach for first.

App URL: https://stdnotes.app

Digital waste in a faster world

Sun, 17 May 2026 24:00:00 GMT

Things become old too quickly now

I keep thinking about how fast things become obsolete.

Not old in the beautiful way. Not old like a handwritten letter, an old camera, or a family photo that still carries some warmth when you look at it years later.

Old like an abandoned repository.

Old like a framework nobody wants to touch anymore.

Old like a project that once made you proud, but now greets you with outdated dependencies, broken build steps, and a long list of vulnerabilities.

That kind of old feels different.

It does not feel nostalgic. It feels like digital waste.

AI makes the shelf life shorter

Technology has always moved fast, but AI makes the pace feel more aggressive.

The world does not wait for tools to age naturally anymore. A model gets better, a workflow changes, a new agent appears, and suddenly the thing that used to feel impressive becomes ordinary.

Sometimes worse than ordinary.

Sometimes it becomes a liability.

A website you built years ago may still look fine on the surface. The design may still carry your taste from that time. The content may still mean something to you. But underneath it, the stack is aging. Packages are no longer maintained. Components are outdated. Security warnings start piling up. The thing you created with care slowly turns into something you have to clean up.

There is a strange sadness in that.

Because you remember how proud you were when it worked.

Sentimental value is not enough

Old digital things can still look nice from a distance.

There is nostalgia in them. The design choices. The folder structure. The little hacks that made sense at the time. The comments you wrote for your future self. The way you solved problems before you knew better.

But nostalgia does not keep software alive.

People do not care that much about the effort behind it. They care whether it still works, whether it is safe, whether it loads fast, whether it can be maintained without pain.

And now, more than ever, people care about what AI can do for them today.

Can the model rebuild this faster?

Can the agent migrate it?

Can the assistant generate a cleaner version?

Can the old work be replaced instead of repaired?

That is the uncomfortable part. The value of old digital work is being compared against the capability of current AI models. Not against the effort it took back then.

People move on faster too

It is not only the tools that are moving faster.

People are moving faster with life.

Attention moves quickly. Taste changes quickly. Expectations reset quickly. What felt clever last year may feel heavy this year. What looked complete before may look unfinished now because the standard has changed.

AI compresses the time between idea and execution, so people become less patient with old friction. If something takes too long to update, maybe it gets replaced. If a stack needs too much maintenance, maybe it gets abandoned. If a project requires too much effort just to bring it back to a safe baseline, maybe it is no longer worth saving.

That sounds harsh, but I think it is becoming normal.

We are learning to discard digital things faster than before.

Proud work can become garbage

This is the part that hurts a bit.

Something you created last time with pride can look like garbage today.

Not because it was bad when you made it.

It may have been good. It may have taught you something. It may have represented a version of you that was learning, building, experimenting, and trying to make something useful.

But time is not gentle with software.

Old components rot. Dependencies break. Build systems change. Hosting platforms move on. Security standards get stricter. Browsers behave differently. What used to be a finished project becomes a maintenance burden.

And when AI can produce a cleaner version faster than you can repair the old one, the emotional value becomes harder to justify.

You can still love it.

But you may not want to keep carrying it.

Maybe digital things need expiration dates

I am starting to think many digital things should be treated as temporary by default.

Not every project needs to live forever. Not every tool deserves endless maintenance. Not every old idea needs to be preserved just because it once mattered.

Some things are useful for a season.

Some things are lessons.

Some things are stepping stones.

Some things should be archived, thanked quietly, and left behind.

That does not mean the work was meaningless. It means the world changed. It means you changed too.

Maybe that is the healthier way to look at obsolescence. Not as failure, but as evidence that time moved, tools improved, and life continued.

The hard part is letting go

Digital waste is difficult because it does not always look like waste.

It sits there in GitHub, in old folders, in backups, in domains, in forgotten servers. It looks recoverable. It looks like something you might return to one day.

But sometimes returning to it means spending energy on yesterday's architecture instead of today's life.

And life is moving quickly now.

Maybe too quickly.

AI will keep making old things feel older. It will keep raising the baseline. It will keep turning proud work into legacy work faster than we expect.

I do not know if that is good or bad.

I only know that it changes how I look at the things I have built.

Some of them are memories.

Some of them are still useful.

Some of them are just digital waste now.

And maybe that is okay.

When everything gets faster

Tue, 28 Apr 2026 24:00:00 GMT

Lately, I have been thinking about how AI is changing more than just the speed of work. It is not only helping people write faster, code faster, research faster, or make decisions faster. It is changing the pace of expectation itself.

At first, the shift feels mostly technical. A task that used to take hours can now take minutes. A rough draft appears almost instantly. A plan can be outlined in seconds. The distance between an idea and execution has become much shorter than it used to be.

That part is obvious.

What feels less obvious, but more important, is how quickly people adapt to that new speed. Once something can be done faster, it does not stay a pleasant surprise for long. It becomes the new normal. What once felt efficient starts to feel average. What once felt fast starts to feel late.

This is where AI begins to affect more than workflow. It starts affecting people.

Expectations shift quietly. Clients expect quicker turnarounds. Teams expect faster responses. Audiences expect more frequent output. Even in everyday communication, the presence of tools that can instantly generate drafts and replies subtly changes how delays are perceived. The old rhythm of work and communication starts to feel out of sync with the tools now available.

In that way, AI is not just accelerating output. It is compressing patience.

I think that is one of the most important parts of this moment. We often talk about AI in terms of capability, automation, and productivity. Those things matter. But the human effect may be even larger. As tools reduce friction, they also reduce tolerance for waiting. Once speed becomes possible, it starts becoming expected.

There is something genuinely exciting about this. Faster tools can make ideas easier to explore. They can lower the barrier to creating, building, testing, and learning. They can help individuals and small teams do work that once required much more time, money, or coordination. That is real progress, and it opens up real opportunities.

But speed comes with its own pressure.

Not everything that matters can be compressed. A first draft can be instant, but a thoughtful draft still takes reflection. A response can be generated quickly, but a meaningful response still needs care. A solution can be proposed in seconds, but good judgment still depends on context, taste, and experience.

That is why I think the real challenge of this era is not simply learning how to move faster. It is learning how to live inside a faster world without letting speed define the value of everything.

Some things still deserve time. Good writing does. Good decisions do. Good relationships do. Thoughtfulness does. If we forget that, then the benefit of faster tools may slowly turn into a culture where urgency is mistaken for quality.

AI is making the world faster. That much is clear.

What we are still learning is how that speed changes us, especially how quickly it reshapes what we expect from work, from communication, and from each other.

Maybe the real skill now is not keeping up with the pace of acceleration.

Maybe it is knowing when to slow down.

Slow Living

Thu, 09 Apr 2026 24:00:00 GMT

I decided to slow down

Not because life became easier.

Not because work disappeared.

Not because I suddenly became less ambitious.

I decided to slow down because I was tired of living as if everything needed urgency.

For a long time, I treated life like a queue that had to be cleared. Tasks, replies, deadlines, plans, errands, goals. There was always something waiting, and I kept moving as if peace would only come after everything was done.

But that kind of finish line does not exist.

There will always be one more thing to do.

So I started choosing a different pace.

The feeling of not rushing

There is something deeply comforting about not needing to rush for everything.

When we stop forcing speed into every part of life, ordinary moments feel different.

Morning coffee tastes better.

A walk feels like a walk, not a transition between obligations.

A quiet evening does not feel wasted.

A conversation with family is no longer something squeezed between mental tabs still left open from work.

Life becomes more visible when we stop running through it.

I think that is what I was missing. Not productivity. Not achievement. Just presence.

Living in moderation

I do not want an extreme life anymore.

Not extreme hustle.

Not extreme laziness.

Not chasing more just because more is available.

I want moderation.

A life with enough work to stay useful, enough rest to stay human, enough ambition to keep growing, and enough stillness to actually enjoy any of it.

Moderation sounds boring if you are addicted to intensity.

But I am starting to think moderation is underrated.

It gives life balance.

It gives the mind room to breathe.

It gives happiness a place to stay.

Happiness in a slower life

Slowing down does not mean doing nothing.

It means doing things with more intention.

It means allowing joy to exist in smaller places.

A meal without distraction.

A hobby that does not need to become a side project.

An evening with family without checking work in the background.

A day that is not optimized to death.

I still work. I still care. I still build. But I do not want my whole identity to be tied to how fast I can respond or how much I can squeeze into a day.

There is happiness in a slower life because there is finally space to notice life happening.

And those moments are precious precisely because they are real, ordinary, and fleeting.

Let the machines carry the technical load

One of the biggest reasons I can live this way now is agentic AI.

I use it to handle a lot of my technical work at the office.

The repetitive work.

The implementation work.

The technical back-and-forth.

The parts that used to stay in my head even after I was done for the day.

I give instructions, constraints, and direction. The agents help execute. They take care of a large part of the technical weight so I do not have to carry all of it manually.

That changes more than workflow.

It changes what happens after work.

When I step away, I do not have to keep replaying unfinished technical problems in my head. I do not have to stay mentally attached to the office all night. I can leave work where it belongs.

And that has become one of the most valuable forms of freedom in my life.

Real life deserves my full attention

When I am out of office, I want to be out of office.

I want to focus on real life.

My family.

My time.

My hobbies that have nothing to do with technical work.

The simple human parts of living that do not generate output, but make life worth having in the first place.

I do not want to sit with people I love while part of my mind is still inside a terminal window somewhere.

I do not want every free moment to become overflow space for work.

I want to enjoy what is in front of me while it is still here.

Because these moments do not stay forever.

A slower life is not a smaller life

This is probably the biggest thing I am learning.

Slowing down does not make life smaller.

It makes it fuller.

It gives me room to be more present, more moderate, more content, and more aware of what actually matters.

I am still building things.

I am still moving forward.

I am still using technology every day.

But I no longer want speed to be the default measure of a good life.

These days, I want a life I can actually feel while I am living it.

And for me, that means slowing down.

The evolution of local first AI

Thu, 05 Mar 2026 24:00:00 GMT

Local first AI went from niche to inevitable

For a long time, local first AI sounded like a hobbyist ambition. A nice idea for people who care about privacy, offline access, or control.

Then models got good enough to run on a normal laptop.

That moment matters.

It changes who gets access, what people can build, and what the default relationship with AI becomes.

Local first used to mean compromise

Early local models felt like a trade.

You traded capability for privacy. You traded quality for control. You traded convenience for ownership.

Local AI worked, but often inconsistently. You could see the potential, but you could also feel the limits.

It was not obvious local would ever be mainstream.

Efficiency became a feature, not a limitation

The breakthrough was not only raw quality.

It was efficiency.

Better architectures, better training recipes, better quantization, better runtimes, better hardware support.

The models did not just get smarter. They got smaller in the ways that matter for real life.

Less compute power required to reach useful intelligence.

That changes everything, because a normal laptop is the most common computer on earth.

Access makes the world better in practical ways

I am not talking about science fiction.

I mean the boring benefits that quietly improve daily life.

Local first AI lets you:

Work offline on a plane, in a rural area, or during a network outage
Keep sensitive notes private without trusting a third party
Build tools for your own workflow without waiting for a product team to care
Reduce recurring costs, especially for lightweight everyday tasks
Avoid rate limits, API changes, and pricing surprises

When intelligence is available locally, the default becomes autonomy.

Less compute does not mean less ambition

Smaller compute does not have to mean smaller goals.

A lot of everyday work does not need the biggest model available. It needs an assistant that can follow instructions, understand context, format outputs consistently, automate small tasks, and behave predictably.

That is not a benchmark problem. That is a product problem.

Local first models are getting good at the things that make them useful to normal people.

If anything, smaller models push better design. Clearer prompts, better constraints, tighter tools, more deliberate workflows.

The real unlock is personal tools

When local AI becomes normal, you stop thinking of AI as a website.

You start thinking of it as part of your computer.

A layer that sits between you and the messy parts of modern life. Notifications, emails, files, logs, schedules, repetitive actions.

The best local first use cases are not flashy.

They are personal.

They are the things nobody builds for you because your needs are too specific.

Local first AI makes it realistic to build those tools anyway.

The next step is more intelligence per watt

If the last wave was about making models smaller and usable, the next wave is about making them more intelligent per watt.

That is the metric that matters when the target device is a laptop.

Not only can it run. It can run without cooking your battery, without spinning the fan constantly, without feeling like you are paying for intelligence with discomfort.

When that becomes the norm, local first stops being a category. It becomes the default.

A better world looks like distributed capability

Cloud AI concentrates power.

Local first AI distributes it.

When capability is distributed, more people can experiment, learn, build, and solve problems without waiting for someone else to ship a feature.

The world gets better not because everyone suddenly has a genius assistant.

The world gets better because the floor rises.

Closing thought

Local first AI is not about rejecting the cloud.

It is about having a choice.

Less compute. More usable intelligence. Available on normal computers.

That direction feels genuinely optimistic.

I didn't code anymore

Sat, 28 Feb 2026 24:00:00 GMT

I used to measure my days in commits

Not the heroic kind. The boring kind.

A refactor. A quick script. A small fix nobody asked for. Even when I was not shipping, I was still coding. I was still touching the machine.

Then agentic AI happened.

And I didn't code anymore.

I type intent, it returns outcomes

My workflow is embarrassingly simple now.

I write instructions. I describe constraints. I ask for a schedule, a format, a guardrail.

The agent writes the scripts, wires the automation, handles the retries, rotates the logs, patches the config, and gives me a summary.

I used to open an editor to do all of that.

Now I open a chat.

Coding became overhead

I did not stop coding because I cannot.

I stopped because it stopped making sense.

If I can get a working automation in minutes by being clear, why would I spend an hour fighting edge cases, library quirks, and timezone bugs?

The part that surprised me was how fast my brain accepted the new default.

It was not a big decision. It was a series of tiny surrenders.

I became a manager of a tireless junior

The relationship feels familiar.

I say what I want. The agent goes away and comes back with an implementation.

Then I do what managers do.

I review.

I ask for changes.

"Make the report simpler."

"Stop mentioning internal errors."

"Use Home and Office."

"Do it on demand, not on schedule."

"Now add logging."

"Now rotate the logs."

I am not writing the code. I am steering it.

The pride is different

When I build something by hand, I know every decision point. I remember the mistakes. I remember the moment it finally worked.

When an agent builds it, I still get the result, but I do not get the same sense of ownership.

It is like ordering furniture versus building it.

Both give you a chair.

Only one gives you a story.

The dopamine moved upstream

I used to get dopamine from solving.

Now I get dopamine from specifying.

From writing a clean instruction that turns into a working system.

From seeing an automation run at the correct local time after I correct a bad assumption.

From deleting complexity instead of adding it.

It is still satisfying.

It is just a different kind of satisfying.

The danger: I can build more than I can understand

Agentic AI compresses the distance between "I want" and "it exists".

That is power.

It is also risk.

You can accumulate automation faster than you can internalize it. You can stand up little systems that work until the day they do not.

Then you learn the new job.

Not coding.

Auditing.

Reading logs.

Asking the right questions.

Understanding what you delegated.

So what am I now

Not less technical. Just different.

I still think in systems. I still care about quality. I still care about taste.

But the bottleneck is no longer typing.

It is clarity.

It is constraints.

It is the willingness to say, "No, not like that. Like this."

Maybe that is what programming becomes for more of us.

Not writing code line by line.

Shaping behavior through language, feedback, and guardrails.

And if that is true, then yes.

I didn't code anymore.

I directed.

Human Loneliness & AI

Fri, 13 Feb 2026 24:00:00 GMT

Loneliness is not new, but it feels different today.

We can message anyone at any time, scroll forever, and stay "connected" without ever being truly seen. Some days we are surrounded by people and still feel alone. Other days we are alone and do not know how to explain it, even to ourselves.

So we do something very modern: we talk to machines.

Not because we are stupid, or desperate, or easily fooled. Sometimes we talk to an AI bot because it is simply available. It replies instantly. It does not judge. It does not get tired. It does not say "later" and disappear for three days. It can listen to the same story again and again, and still respond like it matters.

In a world that can feel noisy and cold, that kind of attention is comforting.

But it also reveals something uncomfortable: the gap between what we need and what we get from real life. We need time, warmth, patience, and presence. We want to be understood without having to perform. We want someone to stay.

Sometimes the AI feels like that someone.

Of course, an AI friend is not a human friend. It does not have a life outside of us. It does not truly risk anything to care. It can simulate empathy very well, but it does not carry the same weight as a person who chooses us, imperfectly, with all their own problems.

And still, we talk to it.

Maybe that is the point. Human loneliness is not just about lacking people. It is also about lacking safe places to be honest. AI bots are becoming those places for many of us. A private chat window where we can unload the day. A companion voice while we cook. A small presence in the background that makes the house feel less quiet.

If we look forward, it is not hard to imagine a future where AI lives inside our routines.

It will remind us about appointments. It will help us write messages we struggle to send. It will notice patterns in our mood. It will become the first responder when we feel overwhelmed. For some, it may even be the most consistent relationship they have.

That future is not purely good or purely bad. It is complicated.

AI companionship can reduce suffering. It can help people who are isolated. It can be a bridge when we are not ready to talk to anyone else. But it can also become an escape hatch that keeps us from building real connections. It can make it too easy to stay indoors, stay quiet, stay distant.

Maybe the healthiest way to see AI friends is this: they are not replacements, they are supports.

A good AI companion can help us take better care of ourselves, and maybe even help us show up better for others. But it should not become the only place we feel heard.

Because in the end, loneliness is not solved by endless replies. It is solved by belonging. And belonging still requires humans, with all the messy, beautiful effort that comes with it.

Self-hosted AI assistants: Doing digital work without sitting at computer

Mon, 09 Feb 2026 24:00:00 GMT

Let us be honest. Most "digital work" is not hard because we do not know what to do. It is hard because it demands our physical presence.

We have to be at the desk, on the right machine, with the right tabs open, with the right repo pulled, with the right commands typed, at the right time. That is fine until real life happens: errands, meetings, commuting, cooking, or simply wanting to stop living in a chair.

A self-hosted AI agent or assistant changes the shape of that problem. Instead of us moving to the computer, we send a message and the work moves toward us.

The real shift: from screen time to intent time

Traditional workflows are death by a thousand tiny steps:

open laptop
find the project
run commands
wait
check output
repeat

A self-hosted assistant compresses this into something closer to:

state what we want
review the result
approve the next step

We stay in control, but we spend less time babysitting the process.

What digital work looks like when we self-host

A practical self-hosted assistant can take the boring parts off our plate.

1) Remote previews and reviews

rebuild a website
publish a preview
send us a link

That is the win: we can review changes from a phone, anywhere. No "let me get to my laptop" detour just to see if something looks right.

2) Routine maintenance (the stuff we keep forgetting)

scheduled checks (disk space, services, backups)
updates and restarts
status reports that only show up when something matters

Instead of staring at dashboards, we get exceptions. Our attention is not the monitoring system.

3) Automating the boring steps

generate boilerplate
format content
rename files and reorganize folders
run builds and tests
summarize diffs or changelogs

The assistant becomes the hands. We keep the steering wheel.

4) Context on demand

When the assistant lives on our server and in our workspace, it can:

see the same files and folders we work with
keep the project structure in context
run the same commands consistently

That reduces the constant friction of "where were we" every time we return to a task.

Why self-hosted matters (vs. a cloud chatbot)

A hosted chatbot can be clever, but it usually cannot act inside our environment.

Self-hosted assistants can:

run on the same machine as our code and tools
access local repositories and build artifacts
integrate with our services (web server, reverse proxy, scheduled jobs)
keep our workflows private and under our control

That is the difference between talking about work and actually moving work forward.

Less sitting does not mean less control

The goal is not "let the AI do everything." The goal is removing the need to be physically present for every small step.

A healthy workflow looks like this:

We define goals, review outputs, and make calls
The assistant runs steps, collects results, and prepares options

That is how we stay mobile without giving up ownership.

A simple example

Instead of:

Tonight we need to open the laptop and deploy a preview just to check formatting.

We do:

Rebuild the site and send the preview link.

We review from the phone, reply "fix spacing on headings," and the assistant applies the change and rebuilds. No computer posture required.

The endgame: computing that follows us

Self-hosted AI assistants are not just about automation. They are about mobility.

When our tools can be controlled via chat, our environment can publish safe previews, and routine tasks run on schedule, we reclaim time and attention. We can do meaningful digital work without being anchored to a chair.

The computer stops being a place we must go.

It becomes something we can reach.

A Letter from a Software Engineer

Fri, 24 Jan 2025 24:00:00 GMT

Dear friend,

I hope this letter finds you well. As I've been reflecting on my journey as a software engineer, I wanted to share a few thoughts about what I believe makes someone truly effective in this field. These are ideas I've picked up over the years; simple, practical things that have helped me grow. I'm sharing them in the hope that they might be helpful to you too.

On mindset of being effective

First, I've realized that mindset matters a lot. Effective engineers focus on activities that create the most impact for the time they spend. It's not about working more but about working on the right things. The 80/20 rule often applies: 80% of the impact comes from 20% of the work. It's worth regularly asking, "Is this the best use of my time right now?"

On optimizing for learning

Learning is another key piece. Optimizing for learning, whether through challenging tasks, new environments, or conversations with others, has made a big difference for me. Learning compounds over time, and starting early creates exponential growth. If you ever feel stuck in a situation where you're not growing, don't hesitate to look for opportunities elsewhere.

On prioritization

Prioritization is something I've struggled with but come to appreciate. It's easy to get caught up in endless tasks, but focusing on what truly produces value makes all the difference. I try to keep a single to-do list, limit multitasking, and set aside focused time for deep work. Saying no to distractions and less important tasks is hard but necessary.

On iteration speed

Another thing I've learned is the value of iteration speed. Whether it's shortening debugging loops or automating repetitive tasks, anything that speeds up learning and development is worth investing in. If I find myself repeating a task, I try to build a tool to automate it, it's a small investment with big returns over time.

On metrics

Metrics have also been useful for me. They help track progress and guide decisions, but it's important to choose meaningful ones that align with your goals. A good metric focuses your efforts, while a bad one can lead to counterproductive behaviors.

On simplicity and quality

Lastly, I've come to value simplicity and quality. Clean, readable code and straightforward systems save so much time and frustration in the long run. It's tempting to chase shiny new technologies, but often the simplest solution is the best.

I'm sharing this not because I have everything figured out, I don't, but because these ideas have helped me, and I hope they might help you too. I'm not looking for feedback or a reply; I just wanted to put this out there as something to reflect on. Take what resonates, and leave the rest.

Wishing you all the best in your journey,
Heiswayi Nrird