DEV Community: Nicholas Masters

Small Models, Strong Guardrails

Nicholas Masters — Wed, 16 Sep 2026 14:31:17 +0000

Small Models, Strong Guardrails

How repository constraints make smaller coding models useful without outsourcing engineering judgment.

I've been experimenting with how far I can push smaller, faster models for real software work.

My workflow lately has been built around ChatGPT's Luna model on Lite mode, Matt Pocock's skills, and GitHub issue tickets for triage, memory, and goal alignment. The model is cheap and fast. Pair that with strong guardrails and a good harness, and you can get a surprisingly capable workflow without burning through tokens or constantly reaching for a frontier model.

I'm currently paying for the $20 Plus plan, and I still haven't consistently hit the limits. Granted, I work a full-time job that isn't currently a developer role, but I use this subscription every day for coding and other work. Being able to use it that often without regularly hitting limits is a big part of the value for me.

The Guardrails

I try to keep my guardrails organic.

I'm not interested in building an enormous collection of prompts that I have to constantly maintain. I want the repository itself to do as much of the steering as possible.

That means things like AGENTS.md, TypeScript's self-documenting nature, solid repository documentation, existing patterns, naming conventions, and reusable skills.

These things make smaller, scrappier models much more useful.

A good example is how I handle React Query. My query and mutation patterns are documented and modular, and the codebase has a shared vocabulary for how things should be named and structured.

When I ask an agent to build a feature, I don't need it to invent the architecture from scratch. I can point it at an existing mutation or query and effectively say, "Follow this pattern for the new feature."

If every mutation uses similar naming, file structure, function signatures, and invalidation patterns, the model has much less to figure out.

I'm reducing the amount of reasoning it needs to do.

That's where smaller models start becoming really effective.

I'm currently using Codex inside VS Code with the Codex extension. I like being able to see the diffs and maintain visibility into exactly what is being written or merged.

I don't take this approach with every project. For one-off experiments, I'm much more willing to let an agent run.

With Disc Golf Labs, it's different.

I care about what gets written there. If I'm going to ship the code, I want to understand the decisions behind it and be able to own those decisions later.

The Pitfalls

There are still plenty of areas where a lightweight, fast model can get you into trouble.

The biggest one is ambiguity.

The stronger frontier models are getting better at inferring intent from a vague task. You can sometimes give them an incomplete idea, answer a few questions, and watch them get surprisingly close to the result you had in your head.

I don't expect that from the smaller models. With them, I'm pair programming. The model and I need to stay aligned on what task we're solving, why we're solving it, and what "done" actually means.

These models also tend to aggressively optimize for the goal you've put in front of them. That's incredibly useful when the goal is clear. It's also one of the biggest foot guns when it isn't.

I've been using Matt Pocock's /grill-me skill for this. The skill forces me to clarify and polish an idea before handing it off for implementation. It helps expose the assumptions that otherwise stay stuck in my head.

/wayfinder is another useful one. It helps define the destination and work backward toward a reasonable path to get there.

Both skills help me align myself and the model before spending a large amount of context or implementation effort.

Staying in the Smart Zone

Context management has also become part of the workflow. In my experience, once a session starts getting much beyond roughly 150k tokens, I trust the model less. I think of that range as the "smart zone," borrowing the term from Matt Pocock's teaching.

A GitHub issue becomes a useful boundary. Finish the task, capture the important decisions, merge it, and start the next task with a cleaner context.

You Are Part of the Model's Ceiling

The floor for building software has risen dramatically. Someone with very little software experience can now produce a working website. It might not be particularly good software, but the fact that they can produce it at all is a meaningful change.

I don't think that makes software engineering expertise less important. I think it changes where that expertise matters. If producing code becomes cheaper, judgment about what code should exist becomes more valuable.

The agent can suggest another abstraction, a view model, five unit tests, or another useEffect. Somebody still has to decide whether any of those things actually belong in the system.

The model doesn't have durable ownership of the codebase. It doesn't have deterministic outcomes. It doesn't truly remember why a decision was made six months ago unless that decision has been captured somewhere it can access.

We need to recognize when the agent is following a pattern versus inventing one. We need to know when a test protects meaningful behavior and when it's just increasing coverage. We need to catch the unnecessary abstraction that looks reasonable in a diff but makes the system harder to maintain.

In that sense, we're part of the model's effective ceiling.

Summary

Lightweight models are extremely useful for building software. With strong guardrails, a good harness, clear task boundaries, and active alignment with the person using them, they can produce meaningful work quickly and cheaply.

The better I get at documenting patterns, defining tasks, managing context, reviewing decisions, and knowing when the model is wrong, the more useful these tools become.

The model is getting better, but so is the environment I put around it. Increasingly, I think that's where the leverage is.

Originally published at https://nmasters.dev/writings/small-models-strong-guardrails/

Graph Engineering: Stop Thinking in Steps, Start Mapping Dependencies

Nicholas Masters — Mon, 10 Aug 2026 18:45:13 +0000

I learned about graph engineering this week.

I expected another hyped-up AI framework.

Instead, I found a simple idea that I now can’t stop seeing everywhere.

It started with the platform I’m currently building.

I was working on the dashboard the same way I normally work through any problem. I’m a list guy. I take the feature, problem, or issue in front of me and break it into smaller chunks of executable work.

Then I work through them one at a time.

It looks something like this…

Determine what data the dashboard needs
Define the API contracts and fetching strategy
Decide how the data should be presented
Break the work into an execution plan

Each step depends on the work that came before it. Finish one, move to the next.

I’ve worked this way for so long that it feels efficient. And to be fair, I’ve gotten pretty fast at it.

But learning about graph engineering made me realize there was another way to structure the same work.

Let me show you what changed.

Instead of asking:

“What are the steps?”

I started asking:

“What actually depends on what?”

That sounds like a small distinction.

It isn’t.

Because my original list implies a dependency that may not actually exist.

For example, do I really need to finish the entire data strategy before thinking about how the dashboard should present information?

Not necessarily.

Once I know the questions the dashboard needs to answer, several pieces of work can begin independently.

I can inspect the available data.

I can sketch the information hierarchy.

I can define loading, empty, and error states.

I can investigate existing API patterns.

I can think through what belongs in summary cards versus charts versus tables.

Those are separate nodes of work.

Some depend on the same input, but they don’t necessarily depend on each other.

That changes the shape of the problem.

My list looked roughly like this:

A → B → C → D

A graph might look more like:

A → B → D

A → C → D

B and C can happen independently.

D waits for both.

And once I saw that, I realized how much of my normal workflow is accidentally sequential.

Not because the work has to happen that way.

Because a list makes it look like it does.

This becomes especially interesting when AI agents enter the picture.

If I give one agent a task list, it will usually work through that list much like I do.

Step one.

Then step two.

Then step three.

The model may be fast, but the structure is still sequential.

Graph engineering moves some of the intelligence out of the individual task and into the structure around the tasks.

You define units of work as nodes.

You define real dependencies as edges.

Then work that shares an input, but not a dependency on each other, can happen independently.

For the dashboard, I could have one branch analyzing the data model while another works through the UI states.

A third could inspect the existing codebase for reusable components.

Another could define acceptance criteria.

They don’t need four completely isolated copies of the project.

They need the right context, a clear responsibility, and an explicit understanding of what their output unlocks next.

When those branches finish, their outputs can converge into the implementation work.

That’s the part that clicked for me.

Graph engineering isn’t really about making a fancy diagram.

It’s about being precise about dependency.

Once those dependencies are explicit, you can see the critical path.

You can see where parallel work is possible.

You can isolate failures.

You can rerun one branch without restarting everything.

And you can give specialized agents smaller contexts instead of asking one agent to carry the entire problem around in its head.

I’m still early in experimenting with this, and I don’t think every problem needs a graph.

Sometimes A → B → C is exactly right.

Adding branches, agents, state, and orchestration to a simple task can easily create more complexity than it removes.

But for larger engineering problems, I’m starting to think the shape of the work matters almost as much as the quality of the individual instructions.

For years, my default has been:

Make a list.

Order the list.

Execute the list.

Now I’m adding another step before that:

Map the dependencies.

Because sometimes the fastest way through a problem isn’t getting better at completing the list.

It’s realizing the list was never a list in the first place.

It was a graph.

From Pro Disc Golf to Code: My Journey to Become a Full-Stack Developer

Nicholas Masters — Wed, 02 Jul 2025 14:06:37 +0000

A year ago I was walking new construction homes as a field manager. I managed the installation of tile wood and carpet in new construction homes. It’s served my family and I well, and put me in situations of self growth I would have never gotten otherwise. But I hit a wall and upward mobility was stagnant. Before I was a field manager I was a professional disc golfer. It was always an adventure, I got to tour the country playing tournaments and teaching clinics. That era instilled in me a deep understanding of planning, discipline, and the power of creating systems to excel.

Current day… I am obsessed with coding. My mind is always buzzing with what I am currently learning, and what technical puzzle I am solving at the time. This passion ignited on a whim last year. I was sent a link to web development coding bootcamp from a family friend. In a whirlwind I called my amazingly supportive wife, and within 20 minutes I was enrolled in the bootcamp. Class started that same day. I had a buzzing in my body, that had me excited and scared all at the same time.

The challenges, the creativity, and the complex problem-solving drove me to fall deep into coding. This post marks the beginning of me sharing my journey. From fairway to construction site to becoming a full stack developer.

Graduating bootcamp last June, the pressure to secure a job intensified with our first child due in February. Despite relentless effort, not a single interview materialized between June and August. Providing for my family meant "biting the bullet" and returning to construction. It felt like taking a quadruple bogey on the tournament's final hole, but just like in disc golf, mental resilience became key. I pivoted. I recognized my skills weren't "up to snuff," especially with AI raising the industry bar. My love for coding made the decision clear: Rise and grind.

That "quadruple bogey" taught me not to let one bad hole ruin the entire round. I went back into the lab and re-evaluated my coding habits and systems, realizing there was immense room for improvement. The "get rich quick" mentality wasn't working. My focus shifted to a long-term, sustainable journey of growth.

One year into this revised plan, I'm already seeing progress. I'm currently interning, building the syllabus website for the very bootcamp I attended – a full-circle moment. This valuable experience, coupled with freelance work and my dedicated side project, is where I'm gaining real-world skills. My current side project, a Disc Golf Course and Round Tracker, directly reinforces my internship learnings in PHP and SQL, allowing me to immediately apply and practice what I'm currently using.

While PHP and SQL aren't my primary languages, this hands-on experience has been truly eye-opening, revealing just how much React streamlines development under the hood. Building reusable OOP components in PHP has definitely made me itch to return to React's ecosystem! Once this internship concludes, my focus shifts to an even bigger project I'm eager to tackle: a MERN stack application.

The road from professional disc golf and construction management to becoming a full-stack developer is proving to be a true test of grit and adaptability. It's a journey I'm embracing fully, learning new languages and paradigms with every step. I'm committed to building a solid portfolio and making this career transition a success. Through this blog, I aim to share the raw, unfiltered experience the “aces” and the "bogeys" if you will. I hope to connect with others on a similar path. Join me as I continue to build, learn, and grow in the world of web development.