DEV Community: Praveen Maurya

Building with Local LLMs: An Engineer's Approach to AI-Assisted Development

Praveen Maurya — Sat, 18 Jul 2026 20:04:50 +0000

I didn't build SafeDevTools by asking AI to "build me a website." I built it by treating a local LLM like a junior engineer who never gets tired of writing boilerplate.

A few weeks ago, I challenged myself with a simple experiment:
Could I build a production-ready product using nothing but a local LLM?

No Claude Code.
No Cursor.
No API credits.
No cloud AI.

Just: VS Code, Ollama (Gemma 4:12B), my MacBook M4 Pro, and a lot of software engineering experience.

The result was SafeDevTools — a collection of privacy-first developer utilities that run entirely in the browser.
👉 https://safedevtools.com

I wrote about the technical "How-To" in my previous article:
How I Built a Premium Developer Tools Website Using Only a Local LLM (Gemma 4:12B + Ollama + VS Code)

This article is about the mental shift. It’s about how I changed the way I think about software development after building this product.

The Biggest Misconception About AI Coding

Every week, social media is flooded with:

"AI built an entire SaaS in 24 hours."
"AI replaces software engineers."

These videos are entertaining, but they miss the point. After spending weeks building a real product with a local model, I realized that the value of AI isn't replacing the engineer.

The value of AI is replacing repetitive engineering work.

That is a massive distinction. One is about replacement; the other is about leverage.

The Evolution of a Software Engineer

Think about your first few years as a developer. Most of your day was spent asking:

"How do I write this loop?"
"Why is my CSS broken?"
"How do I call this API?"

Back then, writing code was the job.

Fast forward a few years. Your role has shifted. You spend your time thinking about:

Architecture & Scalability
Security & Maintainability
Developer Experience (DX)
Deployment Strategy

The irony? Despite becoming responsible for high-level system design, you are still often tasked with writing hundreds of lines of repetitive "grunt work."

The CRUD endpoints. The validation logic. The DTOs. The unit tests. The accessibility attributes.

The code isn't always difficult—it’s just repetitive.

The Realization: Repeating Yourself

SafeDevTools consists of multiple utilities. Every tool follows the same design language:

Responsive layout & Dark mode
Accessibility (A11y) standards
SEO Metadata
JavaScript validation
Consistent styling & Copy buttons

I could have written every page manually. But by the third or fourth tool, I realized something: I wasn't solving engineering problems anymore; I was repeating myself.

That is where the local LLM became my superpower. Not because it "invented" the tools, but because it executed the repetition with perfect consistency.

The Architect vs. The Builder

A key takeaway from this project was learning to separate Intent from Execution.

I found that the most effective workflow is for the human to remain the Architect (Vision, Design, and Standards) while the AI serves as the Builder (Repetitive Tasks, Boilerplate, and Testing).

🏗️ My Responsibilities (The Architect)

Product Vision & UX Decisions
System Architecture & Folder Structure
Coding Standards & Design Systems
Security & Performance Review

🛠️ The Model's Responsibilities (The Builder)

Generating implementation details
Writing boilerplate and repetitive logic
Drafting documentation
Refactoring for readability
Generating unit tests

The mindset shift: The model isn't making product decisions. It is implementing my decisions.

How to Stop Asking AI to "Build Products"

If you want better results, stop using "God-mode" prompts like:
"Build me a dashboard."

Instead, treat the LLM as an implementation engine. Use specific, measurable engineering tasks:

"Generate this Go repository implementation based on these interfaces."
"Build this HTML page following our existing design system."
"Add accessibility improvements without changing the layout."
"Refactor this function while keeping the public API identical."

Pro Tip: These are smaller, discrete tasks. They are exactly where smaller local models perform surprisingly well.

The "Small Context" Secret

Early on, I made the mistake of feeding the model my entire project folder. The results were messy and hallucinatory.

I learned that instead of increasing the prompt size, I needed to reduce the problem scope. Give the model:

One component.
One interface.
One objective.

The smaller the context, the higher the quality of the output. This forced me to be a better architect because I had to define the boundaries more clearly before asking for code.

Your Documentation IS Your Superpower

This was my most unexpected "Aha!" moment. The secret wasn't a complex prompt; it was Standard Operating Procedures (SOPs).

I started documenting everything:

Project structure rules
UI/Naming conventions
Accessibility requirements
JavaScript patterns

Eventually, this evolved into a reusable set of instructions that acted as the "Source of Truth." Once the model understood my project's rules, every new tool became easier to generate.

The documentation became more valuable than any prompt. The AI stopped guessing and started following orders.

Treat Your Local LLM Like a Junior Engineer

This is the ultimate mental model.

Imagine a talented junior developer joins your team today. You wouldn't tell them: "Build our entire platform." They would be overwhelmed and fail.

Instead, you would give them:

Context on how the project works.
The coding standards.
The architectural roadmap.

Then, you review their work.

That is exactly how I use a local LLM. It doesn't replace me; it extends my capacity to build.

Why Local? (The Workflow)

People ask why I don't just use GPT-4 or Claude for this. It’s not about replacing those models; it’s about Workflow.

Privacy: My source code never leaves my machine.
Zero Friction: No API keys, no usage limits, no "Thinking..." delays.
Iteration: I can experiment 100 times without worrying about token costs.
Offline Power: It works anywhere.

The local model is simply another tool in my stack, sitting alongside Docker, Git, and PostgreSQL.

Final Thoughts: AI Didn't Build SafeDevTools.

I need to be clear: AI did not build SafeDevTools.

Human designed the architecture.
Human defined the UX.
Human established the privacy-first philosophy.
Human chose the browser-only execution model.

The implementation simply became dramatically faster because I had an assistant that never complains about writing repetitive code.

The future isn't about "Autonomous Agents" replacing engineers. It’s about experienced developers who know how to combine their Engineering Intuition with AI-Assisted Implementation.

Experience tells you what should be built. AI helps you build it faster.

Stop asking AI to replace you. Start using it to unburden you.

Resources

🌐 SafeDevTools

https://safedevtools.com

📝 The Technical Deep Dive

How I Built SafeDevTools Using a Local LLM

How I Built a Premium Developer Tools Website Using Only a Local LLM (Gemma 4:12B + Ollama + VS Code)

Praveen Maurya — Thu, 25 Jun 2026 19:19:16 +0000

Over the past few weeks, I’ve been experimenting with local language models. Like a lot of developers, I’ve used cloud AI assistants quite a bit, but I kept asking myself one simple question:

Can a local LLM actually help me build a real, production-ready project?

So I decided to find out for myself.

I challenged myself to build an entire developer tools website using only a local AI model running on my own machine. No cloud assistant. No external API. Just my laptop, VS Code, Ollama, and Gemma 4:12B.

The result is SafeDevTools — a collection of browser-based developer utilities with a modern glassmorphic interface, strong SEO foundations, and a privacy-first architecture. You can check it out here: https://safedevtools.com

The site includes tools like:

JSON formatter
JWT parser
Base64 encoder/decoder
Hash generator
CSV to JSON Converter
URL encoder/decoder
Timestamp converter
JSON <-> YAML converter

Honestly, the biggest surprise wasn’t the model itself.

It was how much of a difference a well-written Copilot Skill made.

The Stack

I kept the stack intentionally simple:

VS Code Copilot Agent
Ollama
Gemma 4:12B
HTML
CSS
Vanilla JavaScript

Everything running on Macbook M4 Pro 24GB RAM

That’s it.

No React.

No Angular.

No backend.

No build tools.

No server-side rendering.

And that simplicity mattered more than I expected. It meant the local model could focus on generating clean frontend code instead of getting distracted by framework complexity or project scaffolding.

Running everything on a MacBook M4 Pro with 24GB RAM was also a big advantage. It gave me enough headroom to work comfortably with a local model while keeping the entire workflow fast, private, and fully under my control.

The Biggest Problem

At the beginning, Gemma’s output was a bit all over the place.

Sometimes the layout looked great.

Sometimes the HTML structure changed for no obvious reason.

Some tools used different colors.

Some pages forgot SEO metadata.

Others skipped accessibility or responsive behavior.

The code worked, but it didn’t feel like one project. It felt like a bunch of separate pages written by different people.

That’s fine for a quick prototype, but it doesn’t really work when you’re trying to build something bigger and more consistent.

The Turning Point: Writing a Copilot Skill

Instead of writing longer prompts every time, I created a detailed VS Code Copilot Skill.

That changed everything.

Rather than telling the model what to build each time, I taught it how every tool should be built.

The skill defines things like:

Project architecture
Folder structure
UI design system
Color palette
Glassmorphism styling
SEO requirements
Accessibility standards
Performance expectations
JavaScript architecture
Privacy messaging
Advertisement placeholders
Responsive layouts
Error handling

So every new tool starts from the same standards.

Once that skill was in place, the consistency improved a lot. The pages started to feel like they belonged to the same product instead of being stitched together from random outputs.

That was the real breakthrough.

Instead of constantly correcting the model, I was giving it a reusable engineering blueprint.

Why Local AI Worked Surprisingly Well

Gemma 4:12B isn’t the biggest model out there.

But once the skill encoded the project’s standards, the model didn’t have to invent everything from scratch anymore. It just followed the blueprint.

That made a huge difference.

It reduced weird output, improved consistency, and produced much cleaner code than I was getting from loose, ad-hoc prompts.

If I had to sum up what I learned in one sentence, it would be this:

Smaller models become much more useful when you give them better instructions instead of just bigger prompts.

That really stuck with me.

A Privacy-First Website

One of the main goals for SafeDevTools was making sure every tool runs entirely inside the browser.

Whether you’re:

decoding a JWT
formatting JSON
generating Hash
encoding Base64
converting csv to json
converting timestamps
converting json <-> yaml
encoding or decoding URLs

your input data never leaves your computer.

There are:

no API calls
no uploads
no server-side processing

Everything happens locally using browser APIs and JavaScript.

That was important to me because a lot of developer tools deal with sensitive data. Sometimes you’re pasting tokens, logs, config files, or snippets you really don’t want sent anywhere. With SafeDevTools, that concern just goes away.

It also makes the site feel fast and lightweight, which is always a nice bonus.

Why I Chose Glassmorphism

I didn’t want another plain developer tools website.

A lot of utility sites are useful, but they look a little dated or too functional. I wanted SafeDevTools to feel more like a premium desktop app than a basic web page.

So I leaned into a glassmorphic design style with:

dark slate backgrounds
layered glass surfaces
subtle blur effects
smooth hover animations
modern typography
carefully chosen accent colors

The goal was to make the site feel polished without making it flashy for the sake of it.

And I think that matters more than people admit. Good developer experience isn’t only about whether a tool works. It’s also about whether you actually enjoy using it.

When a tool looks and feels premium, it changes the whole experience.

Simplicity Wins

Every tool is completely self-contained.

Each one lives in its own folder with only three files:

tool-name/

├── index.html
├── style.css
└── script.js

That structure keeps things clean and easy to maintain.

The root project stays minimal too, with just the homepage and the global project files. Nothing feels bloated, and adding a new tool doesn’t turn into a messy refactor every time.

That simplicity ended up being one of the best decisions I made. It makes the project easier to scale, easier to debug, and easier to hand off to the model without confusing it.

What I Learned

The biggest lesson from this project wasn’t really about AI.

It was about software engineering.

AI gives much better results when you give it clear architecture, coding standards, and reusable constraints. That sounds obvious, but I think a lot of people still treat prompts like magic spells instead of treating them like part of the engineering process.

The Copilot Skill became more valuable than any single prompt because it captured the project’s decisions in one place.

Instead of repeating myself over and over, I encoded my preferences once and reused them across every new feature.

That made the whole workflow feel calmer, faster, and much more predictable.

Final Thoughts

Local LLMs are often compared to much larger cloud models, and I get why. But after building this project, I think that comparison misses the point.

A well-instructed local model can be a really solid development partner for structured engineering work.

With the right architecture, reusable skills, and clear project standards, even a 12B parameter model can help build polished, production-ready applications.

For me, this experiment was never about replacing cloud AI.

It was about proving that thoughtful software engineering, combined with local AI, can produce something genuinely useful.

And honestly, seeing SafeDevTools come together — fully offline, privacy-first, and polished enough to feel premium — was more satisfying than I expected.

If you want to see the result, here it is again: https://safedevtools.com