DEV Community: Ammar Najjar

More RAM Changed What Matters in My Local AI Setup

Ammar Najjar — Sat, 26 Sep 2026 11:11:34 +0000

Six months ago, I started running local LLMs seriously on a Mac with 16 GB of unified memory. Most of my decisions were dictated by memory: which models fit, which quantization to use, and how much context I could afford.

Moving to 48 GB changed that.

Models such as Qwen3.8-27B became practical for everyday use, and my attention shifted toward a different problem: how well does the model work during a real coding-agent session?

Memory Was Only the First Constraint

My current setup uses LM Studio with Qwen3.8 and Splash, while OpenCode provides the agentic coding workflow.

With enough memory to run larger models comfortably, other constraints became much more visible.

Context length has a direct cost. Longer sessions accumulate tool output and code. Compaction can interrupt the flow earlier than expected. Thinking improves some tasks while adding latency to others.

A model that looks impressive in a short prompt can therefore feel quite different when it has to navigate a repository, inspect several files, use tools, make changes, and preserve enough context to continue reasoning about them.

That changed how I evaluate local models.

I care less about whether a model technically fits on my machine. I care more about how long I can work with it before the workflow starts getting in the way.

The Setup I Actually Use

After quite a bit of experimentation, the stack has become relatively small:

Mac with 48 GB unified memory → LM Studio → Qwen3.8 / Splash → OpenCode

The interesting optimization work now happens around that stack: choosing a sensible context size, deciding when thinking is worth enabling, understanding why compaction happens, and balancing model capability against interactive speed.

There is still plenty to experiment with, but having more memory has made the trade-offs much clearer.

I documented my current configuration, what changed since the original 16 GB setup, and the lessons from using it for actual development work in the full article:

https://ammar-najjar.com/blog/local-ai-setup-six-months-later/

If you use local LLMs with coding agents, I would be interested in comparing experiences. Once model size and memory stopped being your main constraint, what became the next bottleneck?

What Happens When the Team Chooses a Different Approach?

Ammar Najjar — Sat, 19 Sep 2026 08:10:58 +0000

A team is discussing how to solve a problem. You have an approach in mind, probably backed by experience, but the team reaches a different conclusion.

Their approach is reasonable. You can see some risks, but there is no strong reason to override the decision.

So you let them try it.

This sounds like autonomy. The difficult part comes afterward.

How long do you let the approach run before intervening? What happens when progress is slower than you expected? At what point does giving space become waiting too long?

I ran into exactly this tension while trying to change how I lead technical discussions. I wanted to create more room for others to make decisions instead of becoming the person who provides the solution whenever I have a strong opinion.

What helped was adding one small constraint to the experiment: a time boundary.

Instead of leaving the decision open-ended, we could agree on when we would look at the result again. Until then, the team had space to execute its approach. At the review point, we could look at what actually happened rather than debating whose initial idea was better.

That distinction has become useful for me because it separates two decisions that are easy to mix together:

Who owns the approach?

and

When do we evaluate whether that approach is working?

There is more to getting this right, especially around outcomes, constraints, and what should happen at the review point. I wrote about the experience and the practical model I now use in the full article:

👉 Give Autonomy a Time Boundary

If you lead technical discussions, I am curious how you handle this moment: when the team chooses a reasonable approach that you would not have chosen yourself.

Making AI Coding Agents More Efficient: My Local Toolkit

Ammar Najjar — Sun, 23 Aug 2026 17:17:43 +0000

Giving AI coding agents more tools doesn’t necessarily make them more efficient.

After using OpenCode and Claude Code heavily, I started focusing less on adding capabilities and more on controlling the information flowing into the agent.

That means:

searching before reading entire files
choosing between text, structural, and semantic search
reducing noisy command output
keeping sessions focused
defining explicit stopping rules

I’ve documented the toolkit I currently use, including Headroom, RTK, Caveman, Serena, rg, fd, ast-grep, jq, yq, and others, along with how I define their responsibilities in AGENTS.md.

The principle behind all of it is simple:

Give the agent the smallest amount of information necessary to make the next correct decision.

Full post:
https://ammar-najjar.com/blog/local-ai-coding-toolkit/

I Built a Tool to Visualize NgRx Action Flows

Ammar Najjar — Sun, 16 Aug 2026 13:20:16 +0000

As Angular applications grow, NgRx flows can become surprisingly difficult to follow. An action dispatched from a component may trigger an effect, dispatch another action, update a reducer, and continue through several related paths.

I wanted a better way to understand these relationships without manually jumping through the codebase.

That led me to build ngrx-graph, an open-source tool that analyzes Angular and NgRx source code using the TypeScript AST and generates visual graphs of action flows.

Instead of showing the entire application as one massive graph, it lets you focus on a specific action and see how it connects to:

Components
Effects
Reducers
Selectors
Other actions

This can be useful when debugging unfamiliar flows, reviewing code, onboarding developers, or preparing a refactoring.

In the full article, I explain why I built the project, how the static analysis works, some of the challenges I encountered, and where I want to take it next.

Read the full article:
https://ammar-najjar.com/blog/ngrx-graph/

If you work with NgRx, I’d be interested to hear how you navigate complex action flows in larger applications.

angular #ngrx #typescript #opensource #webdev

How I Configure Cloudflare for My Personal Website

Ammar Najjar — Sat, 01 Aug 2026 08:11:47 +0000

Cloudflare has become much more than a CDN. Today it offers performance optimizations, security features, caching options, protocol settings, AI controls, and dozens of toggles that can be difficult to evaluate.

When I migrated my personal website to Cloudflare Workers, I decided to review every setting from scratch instead of relying on defaults. The result is a documented configuration explaining which options I enable, which I leave disabled, and the reasoning behind each decision.

In this article you'll find:

Performance settings worth enabling.
Security features that make sense for a personal website.
Which options I intentionally leave disabled.
Links to the official Cloudflare documentation for every recommendation.

If you're hosting a static site, portfolio, or blog on Cloudflare, I hope this saves you some time.

I'd also love to hear how others configure Cloudflare. Are there any settings you strongly disagree with or think are often overlooked?

Read the full article here:

https://ammar-najjar.com/blog/how-i-configure-cloudflare/

I Rebuilt My Personal Site with Astro + Bun + Cloudflare, Here’s the Full Architecture Breakdown

Ammar Najjar — Thu, 23 Jul 2026 07:26:39 +0000

After years with a heavier Docusaurus/React setup, I decided it was time for something lighter, faster, and more maintainable.

The result is a fully static, high-performance personal website that scores excellent Core Web Vitals while staying simple to develop and deploy.

What I cover in the new post:

Why Astro became the perfect fit (zero JS by default)
Switching the entire toolchain to Bun (spoiler: it feels much snappier)
How the site delivers under 10 KB of JavaScript on most pages
Smart image optimization, automatic dimension injection, and responsive handling
Internationalization (i18n) setup with content collections
The complete deployment pipeline with GitHub Actions + Cloudflare Pages
Dark mode without layout shifts, Shiki syntax highlighting with CSS variables, and more
How local AI tools (running on my Mac) helped shape the rebuild

If you're interested in modern static site architecture, performance-first development, or just want to see a clean, thoughtful stack in action, I think you'll enjoy this one.

Read the full technical deep dive here:

👉 https://ammar-najjar.com/blog/website-architecture/

I'd love to hear your thoughts in the comments:

What stack are you using for your personal site or blog right now?
Are you team static or still running full server-side frameworks?
Any tools you're excited about in 2026?

Looking forward to the discussion!

A Lunch Conversation Changed My Website

Ammar Najjar — Mon, 20 Jul 2026 07:11:50 +0000

A Lunch Conversation Changed My Website

Sometimes, the best engineering decisions don't start with code.

Mine started over lunch.

A simple conversation made me realize that although my personal website still worked, it no longer matched how I wanted to write, experiment, and share my work. Every improvement came with unnecessary friction, and I found myself maintaining the platform more than enjoying it.

That was the moment I decided it was time to rebuild.

I chose Astro, but this isn't really a story about Astro. It's about recognizing when a project has outgrown its foundation, and why rebuilding can be a better investment than continuing to patch what's already there.

In the article, I cover:

Why one conversation changed my perspective.
Why I decided to rebuild instead of iterate.
Why Astro became my framework of choice.
The lessons I learned throughout the migration.

If you've ever looked at one of your side projects and thought, "If I were starting today, I'd do this differently," you'll probably relate.

I'd love to hear whether you've ever rebuilt a project for the same reason.

Full article:
https://ammar-najjar.com/blog/rebuilding-website-astro/

Nine Years on GitHub Pages. Why I Finally Moved to Cloudflare Pages

Ammar Najjar — Fri, 03 Jul 2026 09:51:55 +0000

After almost nine years on GitHub Pages, I decided it was finally time to migrate my personal website to Cloudflare Pages.

The migration itself was easier than I expected, but I still ran into a few interesting challenges around Docusaurus, Yarn, custom domains, DNS, and sitemap generation.

In this article, I explain:

Why I decided to move
What I gained
The issues I encountered
Lessons learned along the way

If you're considering moving your own static site, I hope it saves you some time.

👉 Read the full article here:

https://ammar-najjar.com/blog/github-pages-to-cloudflare/

Have you stayed with GitHub Pages, or have you moved to another platform? I'd love to hear what influenced your decision.