Local AI on an M1 Pro: From "Post-Apocalyptic" Slowness to a Functional Reality

We’ve all seen headlines like this: "The end of paid coding assistants!" or "Run your own private AI locally for free!" As someone who values privacy and hates the dependency on monthly subscriptions, I decided to see if my trusty MacBook Pro (M1 Pro, 32GB RAM) could become my trustworthy coding workstation.

My journey started with a massive failure, moved through a "thinking" loop, and finally landed on a configuration that actually works. Here is how I turned my Mac into a functional local coding station.

---

Phase 1: The "Heavyweight" Disaster with "Qwen 3.5 Coder Next"

I started ambitious. I pulled Qwen 3.5 Coder Next. I thought 32GB of RAM would be enough. I was wrong.

The Experience:

• Initial 'Hi': 25 seconds.

• Coding Task: 7+ minutes to generate just some initial instructions and start writing the variables section for an Arduino script.

• The Culprit: My logs showed the model needed 51.3 GiB of memory. Since I only have 32GB, Ollama had to shove 26GB of the "brain" onto my CPU.

The long wait after a simple "Hi".

 

The painful 7+ minutes of waiting while watching the slow code generation and seeing my computer's memory heavily consumed.

---

Phase 2: The "Thinking" Trap with "Qwen 3.5 9B"

I pivoted to a smaller model: Qwen 3.5 9B. On paper, this should have been lightning fast. However, I ran into a new hurdle: Reasoning Loops.

Even with the smaller 9B model, the "Reasoning/Thinking" phase was taking forever—sometimes up to 7 minutes of "thinking" without a single line of code being written. At one point, it even got caught in a logical loop, and I had to restart the process.

A lot of thinking for 7+ minutes and no action but much less memory consumption.

---

Phase 3: The Breakthrough (The "Nothink" Secret)

The real "Aha!" moment came when I realized I didn't need the model to spend several minutes pondering the meaning of life for a simple Arduino script. I just needed the code.

I used a simple command to bypass the heavy reasoning phase: >>> /set nothink

The difference was huge:

• Total Response Time: 2 minutes and 28 seconds for a complete, complex answer.

• Content Quality: It wasn't just code. It gave me prerequisites, circuit wiring, full Arduino code, security tips, and even improvement ideas.

• Memory Efficiency: The logs show this model is a perfect fit for the M1 Pro. It only used about 9.1 GiB of total memory, meaning 100% of the model layers (33/33) stayed on the GPU (Metal).

This time, with 'nothink', it was spitting out the answer much faster.

---

Technical Insights from the Logs

If you are troubleshooting your own local setup, here is what I learned from the Ollama server logs:

1. Check your Offloading: In my successful 9B run, the logs said: offloaded 33/33 layers to GPU. This is the ideal case. If that number isn't 100%, your performance will be affected.

2. Flash Attention is King: The logs confirmed enabling flash attention. This helps the Mac handle long conversations without slowing down.

3. The "Unified" Advantage: My M1 Pro was able to allocate a recommendedMaxWorkingSetSize of ~26GB. By using the 9B model (which only needs ~9GB), I left plenty of room for my system to breathe.

---

The Verdict: Is it a "Free" Coding Assistant?

Is a "free" local coding assistant possible? Yes—but resources matters. If you try to run massive models on a 32GB Mac, you'll feel like you're back in the era of dial-up.

If this continues to feel this good, I’m considering the ultimate "pro" move: Using this Mac as a headless AI server. I can connect it to a secure network and put it away on a shelf and connect to its "brain" from my other computers for chatting or from within VS Code (with the suitable plugin's of course) or even my phone. My main coding machine stays cool and quiet, while the M1 Pro does all the heavy lifting in the background.

I hope that my little weekend experiment has helped you in any way with insights or inspiration to set on your own journey of finding your own AI independence.

The Rise of the Product Engineer: Title Trend or New Reality?

 

This career topic has been on my mind for a while, and I've been trying to collect more information about it for my own career's sake. And now I think I have an idea clear enough to be shared. I hope it benefits someone out there.

The "Product Engineer" title has exploded in popularity this year. This shift is happening for three main reasons:

• AI-Assisted Coding: Since AI can now handle basic coding tasks, companies need engineers who can move "above" the code to control the requirements (inputs) and the architecture (outputs).

• Flatter Teams: Tech companies are removing middle layers, requiring engineers to be more independent.

• Faster Delivery: To move quickly, the line between "thinking about the product" and "writing the code" must disappear.

However, after talking to managers, recruiters, and "Product Engineers", I realized that not everyone defines this role the same way. Here are the three main types of "Product Engineers" I have observed:

1. The "Label Switch" (Product in Name Only)

In these companies, the title is just a marketing trick. They swapped the word "Software" for "Product," but nothing else changed.

• The Reality: Whether you are a junior or a senior, your job is the same as a traditional "heads-down" coder.

• The Hiring Process: The interview is 100% technical. They don't assess your business knowledge or how you think about users.

• The Day-to-Day: You receive a ticket, you code it, and you move on. The "product" part is just a fancy new sticker on your LinkedIn profile. You might negotiate the requirements or the sequence of shipping things with your PM, but that's the same thing as the past decades in any small to medium startup. Nothing new.

2. The Product-Minded Engineer

This is a more mature approach, often seen in tech companies with a transparent and flexible management style. Here, the engineer is a partner to the Product Manager (PM).

• The Reality: Mid-level and senior engineers are expected to help improve requirements, not just follow them. There is a heavy focus on customer value over "tech talk."

• The Hiring Process: Interviews include a specific section to discuss how you’ve solved user problems, how you collaborate with designers, and how you interact with the PMs in earlier stages.

• The Day-to-Day: About 10% of your time is spent on product strategy. You are a pragmatist who knows when to choose a "good enough" technical solution to help the user faster. However, the PM still holds the final accountability for the roadmap.

3. The "Part-Time PM" Engineer

This is the most intense version of the role and the unicorn of that job title. These companies need someone who can lead a project from a blank page to a finished product.

• The Reality: You are essentially a Product Manager who also writes code. You are responsible for the "Why" and the "How."

• The Hiring Process: Be prepared for deep questions about product frameworks, data analysis, and user research. They want to see if you can lead a squad of engineers.

• The Day-to-Day: You participate in ideation, talk to stakeholders, and conduct user interviews. You shape the work for the rest of the team and ensure the technical output matches the business goals perfectly. Expect extra accountabilities with this version.

---

Conclusion

The software industry is moving away from "coding as a service" toward "problem-solving as a service." Depending on the company, a Product Engineer can be a simple developer or a business leader. If you are looking for this role, make sure to ask during the interview: "How much influence do I actually have over the 'Why' of the product? And am I actually accountable for any decision made?"

My ESP8266 Blog: An Experiment in Minimalist Web Hosting inside a Mushroom House!

A few weeks ago, I did something unconventional: I moved a blog of mine to an ESP8266 microcontroller. Yes, you read that right: a €10 chip with 80KB of RAM now hosts my thoughts on the internet. (plus the SD card shield of course)

To make it even funnier, I decided to place it inside a wooden mushroom house I was recently working on!

As a minimalist who believes in independence and focusing on what matters without unnecessary complexity, this project was more than a technical experiment. It was a return to first principles: control over your own infrastructure, elimination of unnecessary complexity, and the freedom to build things the simplest way possible. What started as a nostalgic journey into hardware became a fascinating lesson about how little you actually need.

The Hardware Reality: Back to Basics

As a Senior Fullstack Developer, I've spent recent years living in high-level languages and cloud infrastructure. Docker containers with gigabytes of RAM, Kubernetes clusters, serverless architectures – all abstractions that make us forget what's really happening under the hood.

The ESP8266 brutally brought me back to reality:

• 80KB RAM total – less than a single high-resolution photo
• 4MB Flash storage – wouldn't fit a single MP3 file
• 80MHz CPU – slower than my first digital camera
• ~20mA power consumption – could theoretically run for weeks on a AA battery (or even better: solar!)

The 16KB Lesson

The best example was a blog post that hit 16KB in markdown. A tiny text from my perspective as a web developer – maybe worth 2-3 screenshots. But for the ESP8266? A disaster. The chip tried to load the text, parse the HTML template, escape special characters... and simply gave up. Instead of the rendered post, it just showed `{{CONTENT}}` – the unreplaced template variable.

The solution? Split the post into two parts, add cross-links, configure redirects. Suddenly I was thinking about memory management again, about buffer overflows, about the physical limits of hardware. Skills I hadn't used since my university days when I experimented with Arduino and embedded C.

It was simultaneously frustrating and refreshing.

The Software Philosophy: Less is More

Writing code for the ESP8266 reminded me how bloated modern web development has become. My current work stack? React, TypeScript, Webpack, Babel, 300MB of `node_modules` for "Hello World". The ESP8266? Vanilla C++, direct hardware access, no dependencies except the ESP8266 library.

The Entire Blog System

```cpp
ESP8266WebServer server(80);
File file = SD.open(filePath);
server.send(200, "text/html", htmlContent);
```

That's it. No ORMs, no middleware chains, no dependency injection containers. Just direct, transparent code. Every line has a purpose.

Traffic Logging with NTP

A particular highlight: I wanted visitor statistics with real timestamps. But how does a chip without an RTC module get the current time? NTP – Network Time Protocol. A few UDP packets to `pool.ntp.org`, offset calculation, done. The same protocol that's been keeping the internet synchronized since 1985.

```cpp
WiFi.hostByName(ntpServerName, timeServerIP);
sendNTPpacket(timeServerIP);
// Wait for response...
unsigned long epoch = secsSince1900 - 2208988800UL;
```

Suddenly I understood NTP not just theoretically – I had implemented it. That's the kind of learning you lose in the cloud era.

The Practical Possibilities: More Than Just a Blog

What surprised me most: How versatile such a mini-server is. The ESP8266 isn't just a blog host – it's a platform for dozens of use cases:

Pilot Projects and MVPs

Got an app idea that needs a backend? Forget Firebase, forget AWS. Flash an ESP8266, write a few REST endpoints, done. Ideal for:

• API prototypes for mobile apps
• IoT dashboards for smart home experiments
• Webhook receivers for automations
• Local development APIs without Docker

Temporary Landing Pages

• Event website for a party next week? ESP8266.
• Wedding website with RSVP form? ESP8266.
• "Coming Soon" page for a side project? ESP8266.

No hosting account, no credit card, no monthly fees. Just boot up, use, shut down.

Internal Tools

• Note taker
• Stock and groceries manager
• Password manager for your home network (offline!)
• File sharing without cloud services
• Monitoring dashboard for other home servers

Educational Projects

• Teaching kids HTML with instant feedback
• Demonstrating networking fundamentals
• Debugging in a transparent environment
• An alternative for web hosting courses

Creative Applications

• Digital picture frame with web interface
• Recipe database in the kitchen
• Personal journal with physical backup (SD card)

The Security Aspects: Reclaiming Control

In an era of cloud leaks and data scandals, there's something reassuring about physically holding your own server in your hand.

What I Control

• The hardware – I can touch it, disconnect it, destroy it
• The software – every line of code is mine, no black boxes
• The data – on my SD card, in my house, under my jurisdiction
• The logs – I decide what gets logged, nothing goes to third parties

What I Don't Control

• My ISP – can see traffic (HTTP, no HTTPS on the ESP8266)
• My router – port forwarding means exposure
• DDoS protection – an attacker could take down my home internet (but my router can partially manage that + an external tunnel can be added for more protection)

But for a personal blog? The threat is minimal. Who wants to DDoS a personal hobby project?

The Freedom Aspect

The most important learning: Platform independence. As a user of big tech, I am trapped:

• Terms of Service
• Content policies
• Monetization requirements
• Data collection

Now? I could write a post about any topic tomorrow, and nobody can censor it. No platform bans, no shadow banning, no "This content violates community guidelines".

For me as a minimalist, this is more than technical independence – it's philosophical consistency. Fewer dependencies mean more freedom. Less complexity means more control. A €10 chip in my hand is more powerful than a million-dollar data center that belongs to someone else.

This is real digital freedom.

The Challenges: Being Honest

Not everything is sunshine. The ESP8266 blog has real limitations:

Performance

• Slow – up to 2-3 second load time per page for pages with many images (caching helps later)
• Single-threaded – only one request at a time
• No compression – GZip would overload the chip

Availability

• Home internet dependent – if my router goes down, the site is gone
• No CDN – visitors from Japan have 300ms latency
• Dynamic IP – DuckDNS must update every 5 minutes

Development Workflow

• No hot reload – every change: SD card out, edit file, SD card in, ESP8266 restart
• Limited debugging – serial port or nothing
• No admin panel – for large files I must physically remove the SD card

Scaling

• ~10 concurrent users maximum – after that it becomes unstable
• File size limits – posts >12KB must be split
• No HTTPS – impossible without additional hardware

But honestly? For a personal blog, these aren't real problems. I don't have 1000 simultaneous visitors. And the 2-second load time? In a world of JavaScript frameworks that download 5MB, that's acceptable.

The Meta-Lesson: Constraints Foster Creativity

The best part of this project wasn't the technology – it was the mindset.

With unlimited resources (cloud, modern hardware) you don't think. You need user tracking? Add Google Analytics. You want images? Throw 4K PNGs on the page. You want a feature? Install an npm library.

With 80KB RAM you must think:

• Do I really need this variable?
• Can I reuse this string?
• Does this function need to be so complex?

This is minimalism in action. Not the absence of possibilities, but the conscious choice for what's essential. Every line of code justifies its existence. Every feature solves a real problem. No bloatware, no "nice-to-haves", no technical debt castle.

It's like Haiku poetry – the constraint of 17 syllables makes the words more powerful. The ESP8266 makes my code better.

What I Learned as a Senior Developer

• Abstraction has a price – Modern frameworks hide complexity, but also understanding
• Performance is relative – A slow ESP8266 blog is faster than many React SPAs
• Ownership matters – Controlling your own infrastructure is liberating
• Constraints are teachers – Limitations force better solutions
• Hardware understanding is valuable – Even in the cloud era, understanding physical reality helps

Who Is This For?

Try it if you:

• Are a developer who wants to rediscover hardware
• Want to run a personal project without cloud costs
• Want to develop understanding of low-level web technologies
• Seek digital sovereignty over your content
• Enjoy tinkering with projects

Skip it if you:

• Need a production service with high availability
• Expect heavy traffic (>1000 visitors/day)
• Absolutely need HTTPS (unless you build a reverse proxy)
• Don't have time for tinkering
• Just want a blog (use WordPress.com)

Conclusion: A Successful Experiment

Would I do it again? Absolutely.

Would I recommend it for a professional client? Absolutely not.

The ESP8266 blog is the perfect hobby project: technically challenging, practically usable, financially cheap (~€15 hardware: the chip + an SD card shield), and philosophically satisfying. It reminded me of forgotten skills, showed new possibilities, and gave me back control over my online presence.

In a world of cloud services, platform monopolies, and monthly subscriptions, there's something wonderfully anarchistic about hosting your content on a €10 chip sitting in your living room.

This is my server. This is my data. This is my platform.

And it just keeps running, consuming less power than an LED bulb, serving content – one request at a time.

You can checkout my recent and most polished version of the code here https://github.com/MahmoudAdly/esp8266-blog-server