DEV Community: Chris

Azura: local-first personal assistant (feedback wanted)

Chris — Fri, 14 Nov 2025 12:04:16 +0000

Hey devs 👋

I'm working solo on a project called Azura and I’d love blunt technical + product feedback before I go too deep.

TL;DR

Local-first personal AI assistant (Windows / macOS / Linux)
Runs 7B-class models locally on your own machine
Optional cloud inference with 70B+ models (potentially up to ~120B if I can get a GPU cluster cheap enough)
Cloud only sees temporary context for a given query, then it’s gone
Goal: let AI work with highly personalized data while keeping your data on-device and making AI compute more sustainable by offloading work to the user’s hardware

Think of it as Signal, but for AI:

private by default
transparent about what leaves your device
and actually usable as a daily “second brain”.

Problem I’m trying to solve

Most AI tools today:

ship all your prompts and files to a remote server
keep embeddings / logs indefinitely
centralize all compute in big datacenters

That’s bad if you want to:

use AI on sensitive data (legal docs, internal company info, personal notes)
build a long-term memory of your life and work
not rely 100% on someone else’s infrastructure for every tiny inference

On top of that, current AI usage is very cloud-heavy. Every small task hits a GPU in a datacenter, even when a smaller local model would be good enough.

Azura’s goal:

Let AI work deeply with your personal data while keeping that data on your device by default, and offload as much work as possible to the user’s hardware to make AI more sustainable.

Core concept

Azura has two main execution paths:

Local path (default)
- Desktop app (Win / macOS / Linux)
- Local backend (Rust / llama.cpp / vector DB)
- Uses a 7B model running on your machine
- Good for:
  - day-to-day chat
  - note-taking / journaling
  - searching your own docs/files
  - “second brain” queries that don’t need super high IQ
Cloud inference path (optional)
- When a query is too complex / heavy for the local 7B:
  - Azura builds a minimal context (chunks of docs, metadata, etc.)
  - Sends that context + query to a 70B+ model in the cloud (ideally up to ~120B later)
- Data handling:
  - Files / context are used only temporarily for that request
  - Held in memory or short-lived storage just long enough to run the inference
  - Then discarded – no long-term cloud memory of your life

Context engine (high-level idea)

On top of “just call an LLM”, I’m experimenting with a structured context engine:

Ingests:
- files, PDFs, notes, images
Stores:
- embeddings + metadata (timestamps, tags, entities, locations)
Builds:
- a lightweight relationship graph (people, projects, events, topics)
Answers:
- “What did I do for project A in March?”
- “Show me everything related to ‘Company A’ and ‘pricing’.”
- “What did I wear at the gala in Tokyo?” (from images ingested)

Standard RAG is part of this, but the goal is an ongoing personal knowledge base that the LLM can query, not just a vector search API.

All of this long-term data lives on-device.

Sustainability angle (important to me)

Part of the vision is:

Don’t hit a giant GPU cluster for every small query.
Let the user’s device handle as much as possible (7B locally).
Use big cloud models only when they actually add value.

Over time, I’d like Azura to feel like a hybrid compute layer:

Local where possible,
Cloud only for heavy stuff,
Always explicit and transparent.
And most of all, PRIVATE.

What I’d love feedback on

Architecture sanity
- Does the “local-first + direct cloud inference” setup look sane?
- Any better patterns you’ve used for mixing on-device models with cloud models?
Security + privacy model
- For ephemeral cloud context: what would you need to see (docs / guarantees / telemetry) to trust this?
- Anything obvious I’m missing around temporary file handling?
Sustainability / cost
- As engineers: do you care about offloading compute to end-user devices vs fully cloud?
- Any horror stories optimizing 7B vs 70B usage that I should know about?
Would you actually use this?
- If you’re into self-hosting / local LLMs:
  - What’s missing for this to replace “Ollama + notebook + random SaaS” for you?

Next steps

Right now I’m:

Testing 7B models on typical consumer hardware
Designing the first version of the context engine and schema

If this resonates, I’d really appreciate:

Architecture critiques
“This will break because X” comments
Ideas for must-have features for a real, daily-use personal AI

Thanks for reading 🙏

Happy to dive into any part in more detail if you’re curious.

You Only Really Need to Learn 2 Languages to Succeed

Chris — Fri, 27 Jun 2025 16:12:59 +0000

Most developers are told they need to learn dozens of languages to stay competitive. One for scripting, one for frontend, one for backend, one for systems, and another five because "they’re trending."

But in reality?

You only need two.
Not any two, but one from each of these two fundamental categories:

🔹 1. A High Level Language (With Garbage Collection)

These are your productive, developer-friendly languages. They manage memory for you, offer rich ecosystems, and help you ship fast.

Examples:

TypeScript
Go
Python
Java
C#

Use these when building:

Web apps
APIs
Scripts
Automation
Data pipelines

🔸 2. A Low Level Language (Without Garbage Collection)

These languages give you precise control over memory and performance. They are used when predictability, speed, or system-level access matters.

Examples:

Rust
C++
C
Zig

Use these for:

Game engines
OS development
Embedded systems
Performance-critical code
Security and cryptography work

🎯 Why Just These Two?

Because most real-world software problems fall into one of these buckets:

High level orchestration like building logic, connecting services, and managing flows
Low level performance like speed, memory management, and hardware interaction

If you can write both, you can:

Build a full stack system on your own
Write efficient backend services and embedded agents
Move between startup MVPs and military-grade firmware

🔧 Smart Pairings

GC Language	Non-GC Language
Go	C++
TypeScript	Rust
Python	C
Java	Rust

You do not need to master all of them. Just pick one solid language from each group and go deep.

🧠 Depth Over Breadth

Mastering a garbage-collected language makes you productive
Mastering a non-GC language makes you powerful

You do not need to chase trends. You need to understand tradeoffs, how systems work, how memory is managed, and how to scale clean code.

Everything else is just syntax.

✅ TLDR

You only really need to learn two languages:

One that frees you to move fast
One that forces you to think clearly

Learn them deeply
Build boldly
Forget the noise

Stop Overengineering in the Name of Clean Architecture

Chris — Sun, 11 May 2025 03:15:29 +0000

Clean Architecture is a great concept. It’s meant to help you write maintainable, modular, and scalable software.

But too many developers treat it like a religion. They follow it blindly, stuffing projects with unnecessary layers, abstractions, and patterns. All in the name of “clean code.”

Let’s be honest, Clean Architecture is often overused, not because the ideas are bad, but because people overengineer the implementation.

A Quick Joke (That Some Devs Write Unironically)

Here’s an example of multiplying two numbers implemented with an absurd number of patterns:

// overengineered-multiplier.ts

// Interface
interface IMultiplier {
  multiply(a: number, b: number): number;
}

// Singleton
class MultiplierService implements IMultiplier {
  private static instance: MultiplierService;

  private constructor() {}

  static getInstance(): MultiplierService {
    if (!MultiplierService.instance) {
      MultiplierService.instance = new MultiplierService();
    }
    return MultiplierService.instance;
  }

  multiply(a: number, b: number): number {
    return a * b;
  }
}

// Adapter
interface IMultiplierInput {
  x: number;
  y: number;
}

class InputAdapter {
  constructor(private readonly rawInput: [number, number]) {}

  adapt(): IMultiplierInput {
    return { x: this.rawInput[0], y: this.rawInput[1] };
  }
}

// Decorator
class LoggingMultiplierDecorator implements IMultiplier {
  constructor(private readonly inner: IMultiplier) {}

  multiply(a: number, b: number): number {
    console.log(`Logging: Multiplying ${a} * ${b}`);
    const result = this.inner.multiply(a, b);
    console.log(`Logging: Result is ${result}`);
    return result;
  }
}

// Proxy
class MultiplierProxy implements IMultiplier {
  constructor(private readonly target: IMultiplier) {}

  multiply(a: number, b: number): number {
    if (typeof a !== 'number' || typeof b !== 'number') {
      throw new Error('Invalid input types');
    }
    return this.target.multiply(a, b);
  }
}

// Abstract Factory
interface IMultiplierFactory {
  create(): IMultiplier;
}

class RealMultiplierFactory implements IMultiplierFactory {
  create(): IMultiplier {
    const singleton = MultiplierService.getInstance();
    const withLogging = new LoggingMultiplierDecorator(singleton);
    const withProxy = new MultiplierProxy(withLogging);
    return withProxy;
  }
}

// Usage
const rawInput: [number, number] = [6, 9];
const adapted = new InputAdapter(rawInput).adapt();

const factory = new RealMultiplierFactory();
const multiplier = factory.create();

const result = multiplier.multiply(adapted.x, adapted.y);
console.log(`Final Result: ${result}`);

All of this just to calculate 6 * 9. This is what happens when design patterns become cosplay.

The Real Problem: Over-Abstraction

Clean Architecture promotes decoupling. That’s good. But too many devs interpret that as "abstract everything."

Example:

interface IUserRepository {
  findById(id: string): Promise<UserDTO>;
}

class UserRepositoryImpl implements IUserRepository {
  constructor(private db: PrismaClient) {}

  async findById(id: string): Promise<UserDTO> {
    return await this.db.user.findUnique({ where: { id } });
  }
}

Then you add a use case on top:

class GetUserByIdUseCase {
  constructor(private repo: IUserRepository) {}

  async execute(id: string): Promise<UserDTO> {
    return this.repo.findById(id);
  }
}

All of this for one database call. This isn’t clean it’s waste.

Common Overengineering Patterns

1. Interfaces and Implementations for Everything

Blindly creating an interface and a class for every service adds friction without real value.

Use it when:

You actually have multiple implementations
You’re building a plugin system or SDK

Don’t use it when:

You only have one implementation
You’re doing it "just in case"

2. Use Case Classes for Simple Logic

class CreatePostUseCase {
  execute(input: CreatePostDTO): Promise<PostDTO> {
    return this.postRepo.create(input);
  }
}

This is a one-line call. Wrapping it in a class adds nothing. Use a service or method directly unless business logic really requires separation.

3. DTO Explosion

type Post = { id: string; title: string; content: string };
type CreatePostDTO = { title: string; content: string };
type PostResponseDTO = { id: string; title: string; content: string };

If the structure is the same across layers, reuse the object. You don’t need a new DTO for every transition unless there’s a reason.

4. Domain Models with No Behavior

class User {
  constructor(public id: string, public name: string) {}
}

If your "domain entity" is just a data wrapper, it’s not a domain model. Add behavior or don’t abstract.

5. Dependency Injection Overkill

@Module({
  providers: [
    { provide: IUserService, useClass: UserServiceImpl },
    { provide: IUserRepository, useClass: UserRepositoryImpl }
  ]
})

DI containers are great. But if you’re not benefiting from polymorphism or dynamic injection, just instantiate the class.

What You Should Do Instead

Start simple. Build complexity only when needed.
Abstract with intent. Not everything needs to be swappable.
Refactor later. Let the structure grow organically as the app gets more complex.
Optimize for clarity. Not for pleasing architecture diagrams.

Clean Code Is Not More Code

Good code is:

Easy to read
Easy to test
Easy to change

It’s not defined by how many layers, decorators, or design patterns it uses.

Final Thoughts

Clean Architecture should serve your code, not the other way around.

It’s a tool, not a rulebook. Use it to solve complexity not to create it.

TLDR

Avoid This	Do This Instead
Interface and Impl for everything	Use one class until you actually need two
Use cases for CRUD logic	Use simple services or methods
Separate DTOs for same shapes	Reuse types where possible
DI for everything	Instantiate directly when practical
Layers for layers’ sake	Let structure grow with real needs

Build software, not monuments.

Of course, if your goal is job security, then by all means abstract everything. Write five layers per feature, name nothing clearly, and inject interfaces into factories into services into use cases. Once the codebase hits 100,000 lines, no one will know what’s going on but you. Congratulations, you’re now unfireable LOL.

TypeScript + Rust: All You Need in 2025

Chris — Sun, 11 May 2025 02:59:58 +0000

Let’s be real. The software landscape is bloated. Between AI hyped frameworks and the constant cycle of JS libraries trying to reinvent the wheel, it’s easy to get lost chasing tech for the sake of it.

But if you're trying to actually build something valuable in 2025, not just keep up with Hacker News, you really only need two languages:

TypeScript and Rust

Why TypeScript?

Because 90 percent of products today touch the web. And when it comes to frontend, API clients, or even backend services, nothing is more practical than TypeScript.

You get type safety without the Java boilerplate
You get first class tooling with VSCode, ESLint, Bun, tsup
You can build full stack apps across Next.js, Node, Cloudflare Workers, Firebase
You move fast without breaking everything

It’s the language of the web. Period

Why Rust?

Because when performance, memory safety, and scale matter, Rust is unmatched

C level performance with zero segfaults
Compiles to WebAssembly or runs as a blazing fast backend
Handles AI pipelines, edge compute, custom databases, file systems
Gives you memory control and fearless concurrency for real workloads

You are not wasting CPU cycles on garbage collection or runtime bugs

What About the Others?

Python
Nice syntax until the codebase grows. The type system is glued on, not designed in. Static analysis is a mess and errors sneak in constantly

Go
Go is great for building simple tools quickly, but it can become a liability at scale. Discord famously dropped Go from their caching system after the garbage collector became a bottleneck. While that specific issue was later addressed, GC performance can still be unpredictable under heavy load. If you need fine-grained control or predictable latency, Go might not cut it.

Java
Enterprise hell. Verbose classes, XML config files, Spring Boot complexity. Java is built for a different era. If you are building modern software today, why are you still using it

Real World Example

In my current projects

Frontend and admin dashboards: TypeScript with React, Chakra, Next.js
Backend logic, APIs, authentication, realtime: TypeScript with NestJS, Firebase, Cloud Run
Data processing, local AI, indexing: Rust with REST API, image parsing, zip and file system crawling
Vector search and storage orchestration: Rust with Qdrant and PostgreSQL

One stack
End to end control
No bloat
No regrets

Final Thoughts

If you master TypeScript and Rust, you are not a JS dev
You are not a systems dev
You are a full spectrum engineer who can build anything from the interface to the infrastructure

In a world filled with AI noise, cloud saturation, and latency pressure

That’s all you need

What are you building with in 2025
Let’s talk in the comments

Don’t Use SQL If Your Client Doesn’t Know What They Want

Chris — Sun, 11 May 2025 02:46:56 +0000

Firestore saved me from schema hell

If you’re building for a client who keeps shifting the goalpost, here’s some honest advice:

Avoid SQL until the spec is stable.
You’ll save yourself from endless migrations, broken data, and wasted hours.

💥 Why SQL is a bad idea in chaotic projects

Every schema change = manual migration
Every migration = rollback risk
Every miscommunication = broken relations or corrupted data

It’s like building a skyscraper with a blueprint drawn in crayon.

✅ Why Firestore (NoSQL) saved me

No migrations
Just start writing data. Add new fields whenever. No tables to alter. No DB admin.
Nested data, no problem
Need a user profile with 5 settings and a subcollection of comments? Firestore handles that like it’s native.
Speed over structure
Perfect for MVPs. When the client changes their mind (again), you don’t have to rewrite half your DB logic.
Schema-less = stress-less
You don’t get yelled at for not “planning ahead.” You just ship.

⚖️ But if you have to use SQL…

Some teams/projects require relational DBs. Here are tools that make the pain tolerable:

Prisma Type-safe, declarative schema, powerful migration engine
Knex.js + Objection.js Mature and battle-tested in Node environments
Atlas by Ariga Clean migration workflows, good for CI/CD
Supabase 🔥 Firebase-like developer experience on top of PostgreSQL
- Instant APIs
- Auth + storage included
- Web UI for managing schema/migrations
- Great for teams that need SQL but want NoSQL-level velocity

Why Supabase is different

Even though it’s SQL under the hood, Supabase makes schema changes easier to manage. You can:

View and edit tables in the dashboard
Auto-generate APIs
Roll back or push migrations with Git workflows

It's a great compromise if your project is too relational for Firestore but still in flux.

TL;DR

If the client says “we’re still figuring it out,” avoid SQL unless you enjoy stress.

✅ Use Firestore when things are unstable or MVP
✅ Use Supabase if you need SQL but want NoSQL flexibility
✅ Use proper migration tools (Prisma, Knex, Atlas) if you're stuck with raw SQL

Choose tools that match the reality of the project, not what sounds good on paper.

I Started My Own Company at 20 and Landed a $70K Contract. Here's What I'm Building Next

Chris — Sun, 11 May 2025 02:41:10 +0000

At 20 years old, I took the leap and officially founded my first company. I’ve been a software engineer since I was 15, leading teams, shipping products, and consulting. But this is different. This is mine.

Just days after incorporation, I closed a $70,000 contract. No funding. No connections. No fancy pitch decks. Just proof of work, relentless execution, and solving real problems fast.

Now I’m channeling that momentum into building something much bigger.

Introducing NousCore My Legacy Project

I won’t spill everything. There are too many eyes and too many people trying to ride waves they didn’t earn.

But here’s what I can share:

• It’s an AI-native platform that runs on the edge, not in the cloud
• It’s built for performance, privacy, and permanence
• It combines my love for systems programming, local-first data, and real-world utility
• It’s memory-efficient, resilient, and doesn’t need a datacenter to function

Think of it as a personal AI system that works for you and not for advertisers, not for surveillance, and not for data farms.

Why I’m Doing This

I’m tired of bloated software and overengineered cloud stacks that leak data and burn budgets. I want to create something powerful, self-contained, and private. Something that lasts.

This isn’t just a product. It’s a statement.

What's Next

I’ll be documenting parts of my journey (without giving away the sauce). From technical breakdowns to startup realities.

If you're into AI, systems design, or just want to build things that matter, follow along.

Let’s make tech that respects people again.

Stop Letting AI Do Your Thinking For You

Chris — Thu, 24 Apr 2025 03:36:12 +0000

Lately it feels like roles are reversing.

Instead of developers using AI as a tool, they are becoming tools for AI.

People plug their entire codebase into Copilot or Cursor, click accept like it is gospel, and think they are building software. You are not. You are just pasting code with no idea where it came from or how it fits into the system you are supposed to understand.

Let me be clear:

I use AI. I use ChatGPT. But I use it like a scalpel, not a crutch.

I do not touch Copilot. I do not rely on Cursor. Why?

Because the second you offload thinking, you lose track of context.

And context is the only real superpower a software engineer has.

No AI today not ChatGPT, not Claude, not anything can keep track of your mental model. They do not know the trade-offs you made last sprint. They do not remember that one brittle API you agreed to avoid touching until Q3. They do not understand why you chose composition over inheritance in a specific module that is now quietly holding your whole app together.

But you do.

Your brain does.

And when you give up your role as the system’s architect to let some autocomplete guess what you need, you become the assistant, not the engineer.

AI is a hammer. You are still the one swinging it.

Use AI to accelerate your thinking. Ask it to break down a regex, write a first draft of a boring config, or summarize documentation. Fine. Great. But never let it own the architecture. Do not let it become your crutch for avoiding complexity.

Because if you do, one day you will open your codebase and realize you do not even recognize the thing you built.

And worse, you will not know how to fix it.

If this resonates, drop your thoughts. I am all for AI, but we need to stop worshipping it like it is the engineer. It is not. You are.

How I Made My SaaS "Students Only" Without School IDs Using WHOIS and GPT

Chris — Thu, 24 Apr 2025 00:49:18 +0000

In building my resume review SaaS tailored for students and 転職活動 (career change) seekers in Japan, I faced a simple question:

"How do I restrict access to just students without relying on official university logins or SheerID?"

A lot of companies solve this using school issued IDs, OAuth through G Suite for Education, or even SheerID verification. But all of those come with integration complexity, potential friction, and worst of all kill the speed and ease of my UX.

So I built something better.

✅ The Goal: Students Only Access With Just an Email

My signup form asks for a university email. That’s it. If your domain is a real school, you’re in. If it’s not, you’re blocked. No ID upload. No OAuth. No API dependency.

⚙️ The Stack

Backend: Node.js (NestJS)
Database: Firestore (for whitelist and blacklist)
External Tools:
- WHOIS lookup
- OpenAI GPT API
No SheerID. No OAuth. No .edu requirement

💡 The Logic

User submits an email like someone@s.chibakoudai.jp
I extract the domain: s.chibakoudai.jp
Check my Firestore whitelist and blacklist
If unknown, use WHOIS and GPT to verify

🔍 WHOIS and GPT Magic

If the domain isn’t already in my whitelist, I check WHOIS to get metadata like:

Organization name
Registrant info
Domain category (often .ac.jp, .edu, etc.)

Then I feed that WHOIS data into ChatGPT with a prompt like:

"Is this domain associated with an educational institution? Just return Yes or No."

If GPT says yes → ✅ add to whitelist

If GPT says no → ❌ add to blacklist and block the user

✨ Example Code Snippet

const whoisData = await lookupWhois(domain);
const prompt = `Is this domain from a university or educational institution?\n\nWHOIS:\n${whoisData}`;

const gptResult = await openai.chat.completions.create({
  model: 'gpt-4',
  messages: [{ role: 'user', content: prompt }],
});

const isSchool = gptResult.choices[0].message.content.includes('Yes');

🧠 Why It Works

Fast UX — Users don’t need to upload IDs or register school portals
Self expanding list — My whitelist grows automatically as GPT verifies new domains
Low Cost — GPT and WHOIS is cheaper and faster than commercial APIs

🔐 What About Abuse

Domains like gmail.com or yahoo.co.jp get instantly rejected
Once flagged, a domain is blacklisted and denied forever
This isn’t a hardcore identity proof — it’s smart friction

🚀 Outcome

Zero authentication integrations
Super smooth UX
Only real students can register
No need to deal with Japanese school bureaucracy (trust me, that’s worth it)

🤖 TLDR

I used WHOIS and GPT to check if an email domain belonged to a school and whitelist it automatically. No OAuth. No ID. Just a clever prompt and database check. Lightweight, fast, and clean.

If you want to implement this or have questions, feel free to drop a comment. Happy to share the logic in more detail

And if you’re working on an AI SaaS and want to avoid auth complexity this might be the easiest "student only" gate you'll ever build.

How I Landed a $150K Contract at 20 While Everyone Else Was Virtue Signaling

Chris — Tue, 22 Apr 2025 10:24:31 +0000

Let’s be real

Most of what you see online from “young founders” is noise

Pitch decks, buzzwords, hackathon demos, endless posts about “building in public”

No users, no product, no revenue

Just vibes

Meanwhile, I’m 20

No college

No investor

No clout

Just skill and execution

And with that alone, I closed a $150,000 contract to build a full-scale SNS platform from the ground up

This post isn’t about bragging

It’s about showing you that you don’t need credentials when you can provide undeniable value

What I Did (That Most Don’t)

1. I shut up and learned to build

I didn’t waste my time posting “day 34 of building my startup” or preaching on LinkedIn

I spent my time mastering:

Full stack engineering (React, NestJS, PostgreSQL, etc.)
Real world infrastructure (GCP, Docker, Firebase, Cloud Run)
Clean architecture, auth systems, deployment pipelines
Systems that actually scale

While others were building MVPs with no understanding of backend security or performance, I built real, working apps

2. I made my skills public through work

No resumes. Just output

I didn’t tell people I could build, I showed them

I took smaller gigs early, overdelivered, built trust, and made sure everything I touched was undeniably professional

Design. Docs. Architecture. Deployment

All clean. All tight

When the $150K opportunity came, there was no question of "can you handle this"

They already knew I could

3. I didn’t act like a founder, I acted like an engineer

I didn’t wear a fake CEO badge or pretend I was changing the world

I scoped the problem, broke it down, communicated clearly, and delivered a real execution plan

That alone made me stand out more than any mission statement ever could

Why It Worked

Because companies don’t care about your startup story

They care about whether you can deliver something that works, that scales, and that solves a problem

I didn’t pretend to be a visionary

I just did the work, and that work turned into value which turned into a $150K payout

Final Words

If you’re young and trying to get in

Stop trying to look impressive. Be useful

Stop preaching about disruption. Start delivering output

Let your craft speak for itself

Because in the end

Value over virtue signaling

Results over resumes

Execution over excuses

I’m 20, I didn’t go to college, and I’m already profiting with skill alone

You can too if you stop playing the game everyone else is playing

Why I Never Use Optimistic Updates (And Why You Might Regret It Too)

Chris — Sat, 19 Apr 2025 14:16:57 +0000

If you’ve built anything with React, Vue, or any modern frontend framework, you’ve probably come across the idea of optimistic UI updates. It sounds fancy. It sounds fast. It even feels good. Until it doesn’t.

Let me tell you why I almost never update state optimistically anymore, and why you might want to think twice before doing it too.

⚡ What Is an Optimistic Update?

Optimistic updates mean changing the UI before you know if the backend operation actually succeeded. For example, you click "like" on a post, and the heart icon turns red immediately, before the API call finishes.

setLiked(true) // optimistic update
await api.likePost(postId)

If something fails, you roll it back:

catch (error) {
  setLiked(false) // rollback
}

Seems harmless, right?

❌ Why I Stopped Using Optimistic Updates

1. Edge Cases Multiply Fast

Every time you write an optimistic update, you're creating an alternate reality. Now you have to write logic to reconcile the optimistic state with the real state if:

The request fails
The data changes from another tab or user
The user undoes the action before the request finishes
The server responds with something unexpected like validation or sanitization

That’s four edge cases for one button. Multiply that across a large app and your UI becomes a ticking time bomb.

2. Rollbacks Are a UX Nightmare

Users hate seeing the UI revert. Imagine typing a message, seeing it appear instantly, and then it disappears because the server threw a 500.

Yes, you can show toasts like “Action failed,” but most people don’t read those. It just feels like your app is broken or buggy.

3. It Breaks Consistency

Your UI state and your backend state go out of sync on purpose when you use optimistic updates. That’s dangerous.

Consistency between client and server is everything in multi-user apps. If you break that contract, you introduce bugs that are extremely hard to debug, especially when multiple users are involved.

4. You’re Not Facebook

Optimistic updates are mostly popularized by companies that can afford massive infra and logic to handle them properly.

You probably have:

A few devs, maybe just you
No conflict resolution backend
No retry queue
No live event stream syncing the UI

Without all of that, optimism is a luxury you can’t afford.

🧠 What I Do Instead: Pessimistic + Immediate Feedback

I do this:

setLoading(true)
await api.likePost(postId)
setLiked(true)
setLoading(false)

And optionally show a spinner or skeleton. Sure, it's 100 to 300 ms slower, but I:

Don’t need to roll anything back
Don’t need to guess what the server will return
Keep the UI and backend state always in sync
Avoid writing extra logic for "what if it fails"

Clean code. Predictable behavior. No surprise bugs at 3 am.

🔄 When I Do Use Optimistic Updates

Okay, I lied a little. I’ll use optimistic updates if and only if:

The failure state doesn't matter, like liking a post that no one else sees
The action is idempotent
I have background sync or retry logic
I’m willing to tolerate inconsistency

In most CRUD apps, not worth it.

💡 Final Thoughts

Optimistic updates are like gambling. Sometimes you win. But when you lose, the debugging cost is massive.

Instead of betting that your API won't fail, just build for the world we live in. A world where servers crash, networks flake, and users click faster than requests resolve.

You don’t need optimism. You need resilience.

✍️ What do you think? Do you use optimistic updates in your app? Have they bitten you before? Let’s talk in the comments.

🚀 How I Boosted Slack RAG Accuracy by 5–6% with Smarter Chunking

Chris — Sun, 06 Apr 2025 04:53:56 +0000

I recently worked on improving chunking strategies for a Slack text RAG (Retrieval-Augmented Generation) system, and I wanted to share my approach — especially for those dealing with chaotic, real-world conversational data.

When you’re trying to retrieve relevant context from Slack conversations, naive chunking can lead to fragmented or unhelpful responses. So I combined three different chunking strategies to make the data much richer and improve retrieval quality.

By doing this, I saw about a 5–6% increase in accuracy, and interestingly, the system gets even more accurate as more data is added. 📈

Let’s dive in! 🧩

🧩 The Problem: Slack Conversations Are Messy

Slack messages are fast-paced and fragmented:

Conversations happen across multiple channels.
Threads are scattered.
Messages are often short and informal.
Context gets lost easily if you chunk blindly.

My goal was to feed high-quality chunks into the vector store for better context retrieval, especially for RAG systems. So I experimented with multiple chunking techniques to capture as much context as possible in each chunk.

🧠 Strategy 1: Token-Based Chunking (Contextual Enrichment)

The first thing I implemented was token-based chunking.

Instead of chunking by a fixed number of messages, I chunked by token count (e.g., ~500 tokens per chunk). This ensured:

Each chunk was dense with meaningful information.
I avoided splitting messages awkwardly.
I could control the input size for my LLM efficiently.

Bonus: Token-based chunking allowed me to enrich each chunk with metadata (timestamps, user IDs, thread info) while staying within token limits.

📝 Why it matters:

Token limits are very real when you’re dealing with LLMs. Efficient token-based chunking helps maximize signal while respecting those limits.

⏱️ Strategy 2: Timestamp-Based Chunking (5-Minute Windows)

Slack conversations often happen in bursts.

To capture that natural rhythm, I implemented timestamp-based chunking, grouping all messages within a 5-minute window.

This helped me capture:

Natural conversation flow.
Real-time back-and-forth.
Standalone short discussions.

📝 Why it matters:

By keeping chunks within natural conversational timeframes, retrieval felt more human. When the model retrieved context, it got the full flow of that moment in time.

🧵 Strategy 3: Thread-Based Chunking

Slack threads are goldmines of context.

To avoid fragmenting them, I chunked entire threads as a single chunk.

This way:

Every reply and reaction in a thread stayed together.
I avoided splitting up follow-up questions and answers.
Models could "read" the whole conversation without gaps.

📝 Why it matters:

Thread-based chunking keeps related ideas intact, which is critical for meaningful retrieval in Q&A scenarios.

📊 The Impact: 5–6% Accuracy Boost (And It Scales!)

By combining these three strategies, my Slack RAG system became noticeably smarter:

✅ More relevant context retrieved.
✅ Better grounding for generation tasks.
✅ Less noise in retrieval results.

I measured about a 5–6% increase in retrieval accuracy, and I noticed something exciting:

The accuracy improves even further as the dataset grows.

This makes sense:

The richer the chunks, the better your embeddings.
As you add more data, there’s a higher chance of finding meaningful matches.
Chunking effectively compounds its benefits over time.

If you’re scaling your data ingestion, this is an optimization that keeps giving back!

🚀 Takeaways for Your RAG System

If you’re building any RAG system, especially with noisy chat data, I highly recommend combining chunking strategies.

Here’s your actionable playbook:

✅ Token-based chunking to manage LLM input limits efficiently.
✅ Timestamp chunking to preserve natural conversation flow.
✅ Thread chunking to keep full discussions intact.
✅ And remember: the bigger your dataset, the more these strategies shine! 📈

Experiment and find the right balance for your use case.

💡 Pro Tip

Consider layering these strategies together:

First, chunk by thread.

Then, within threads, chunk by token count if they’re too big.

For non-threaded conversations, use timestamp-based chunking to group messages naturally.

It’s a multi-step process, but the quality of your retrieval will thank you.

💬 What’s Next?

I’m thinking about pushing this even further by exploring:

Hybrid chunking (e.g., timestamp + thread + token cap).
Sentiment-aware chunking (grouping emotional bursts together).
Speaker role-based chunking (grouping moderator/admin messages separately).

Would love to hear your thoughts — how are you handling chunking in your RAG systems? Drop a comment below! 🚀

🧪 Types of Software Testing and What They Actually Accomplish

Chris — Fri, 28 Mar 2025 14:54:43 +0000

Whether you're launching a new feature, shipping a hotfix, or building a system from the ground up, testing is what keeps your code safe, sane, and solid. But with all the buzzwords flying around—unit tests, integration tests, E2E—it's easy to get lost.

So let’s break down the main types of software testing, what they actually accomplish, and when you should use them.

🧩 1. Unit Testing: Test the Smallest Pieces

What it is:

Tests individual functions or methods in isolation.

Goal:

To verify that each "unit" of your code (like a function or class) works as expected.

Tools:

JavaScript: Jest, Mocha
Python: unittest, pytest
Java: JUnit

Example:

// JavaScript example
function add(a, b) {
  return a + b;
}

test('adds 2 + 3 to equal 5', () => {
  expect(add(2, 3)).toBe(5);
});

What it accomplishes:

Catches bugs early
Makes refactoring easier
Improves code reliability

🔗 2. Integration Testing: Test How Pieces Work Together

What it is:

Tests multiple components or modules working together (e.g., database + backend).

Goal:

To ensure integrations between services, modules, or layers (like API ↔️ DB) are functioning.

Tools:

Postman
Supertest
Pytest (Python)
Spring Test (Java)

Example:

Test that a REST API endpoint creates a new user in the database correctly.

What it accomplishes:

Catches issues with data flow
Verifies contracts between components
Prevents regression when APIs change

🌐 3. End-to-End (E2E) Testing: Test the Whole App Like a User

What it is:

Tests the entire application from the user’s perspective, from frontend to backend.

Goal:

To simulate real user scenarios and verify the app works as expected.

Tools:

Cypress
Playwright
Selenium
Puppeteer

Example:

What it accomplishes:

Confirms the system works as a whole
Detects real-world failures
Increases confidence before release

🔄 4. Regression Testing: Test Old Features After New Changes

What it is:

Re-running old test cases to ensure existing functionality still works after updates.

Goal:

To prevent bugs from creeping back into previously working code.

Usually done using:

Automated test suites (unit + integration + E2E)

What it accomplishes:

Ensures stability with each release
Helps maintain trust in legacy systems
Reduces risk during updates/refactors

👀 5. Manual Testing: Human-Powered Validation

What it is:

Testing done manually by a tester or developer, clicking around and verifying behavior.

Goal:

To catch UI/UX issues, edge cases, or things automation can’t.

Great for:

Exploratory testing
Usability testing
Complex interactions

What it accomplishes:

Detects subtle bugs or weird behavior
Validates user experience
Complements automated tests

🧠 6. Acceptance Testing: Meet the Requirements

What it is:

Tests whether the product meets business requirements and is ready for delivery.

Goal:

To verify that the software does what the stakeholder or customer expects.

Tools:

Cucumber (BDD)
FitNesse
Manual acceptance checklists

What it accomplishes:

Ensures business logic is correct
Helps align devs and stakeholders
Validates "done" criteria before shipping

🔐 7. Security Testing: Stay Safe Out There

What it is:

Testing focused on vulnerabilities, data protection, and access control.

Goal:

To find security holes like XSS, SQL Injection, broken auth, etc.

Tools:

OWASP ZAP
Burp Suite
Static code analysis tools (Snyk, SonarQube)

What it accomplishes:

Protects against exploits
Builds user trust
Ensures compliance (HIPAA, GDPR, etc.)

⚙️ 8. Performance & Load Testing: Can It Handle the Heat?

What it is:

Tests how your app performs under load, stress, and varying conditions.

Goal:

To find bottlenecks, memory leaks, or scalability issues.

Tools:

Apache JMeter
k6
Gatling
Locust (Python)

What it accomplishes:

Ensures smooth experience under traffic
Prepares systems for scaling
Avoids crashes on launch day 🚀

🔁 Bonus: Smoke & Sanity Testing

Smoke Testing: A quick check to see if the core functions work before diving deeper.
Sanity Testing: Verifying a small change or fix didn’t break related features.

Think of them as your morning coffee checks ☕—quick sanity savers.

📌 Final Thoughts

Software testing isn't just a checkbox—it's a mindset.

Each type of test plays a unique role in protecting your codebase and giving you the confidence to ship faster, safer, and smarter.

Here’s the cheat sheet:

Test Type	Purpose	When to Use
Unit	Test individual functions	During development
Integration	Test connections between parts	After modules are complete
End-to-End	Simulate real user behavior	Before major releases
Regression	Ensure nothing broke after changes	Every sprint/release
Manual	Catch UI/UX bugs humans notice	For exploratory sessions
Acceptance	Meet stakeholder expectations	Before sign-off/delivery
Security	Protect against vulnerabilities	Regular security audits
Performance	Check scalability and speed	Before high-traffic launches

💬 Got a favorite testing setup or war story from production? Let’s talk in the comments!
🛠️ Follow me for more dev deep-dives, architecture tips, and real-world engineering breakdowns.