DEV Community: Shrestha Pandey

Mojo Hits 1.0: A Technical Look

Shrestha Pandey — Fri, 21 Aug 2026 11:41:21 +0000

On August 11, 2026, Modular released Mojo 1.0 as part of the broader Modular 26.5 platform update. This is not a minor version bump dressed up with marketing language. It closes a three-year period during which the language's syntax, standard library, and core semantics changed release over release, often breaking source compatibility for anyone maintaining a nontrivial codebase on top of it. This article examines what changed at the language level, what the stability guarantee actually covers, how the memory model and GPU targeting evolved, and where the language still has real gaps.

Why 1.0 is a governance change

Since Modular open-sourced the Mojo standard library in 2024, the project has taken in roughly 1,100 pull requests from close to 200 external contributors, touching more than 200,000 lines of code, with well over a thousand additional issues filed by the community. That volume of contribution is a healthy sign for an open-source project, but it also explains why pre-1.0 Mojo was difficult to build durable software on: Modular was using the language internally to build its own commercial infrastructure — the MAX inference framework and Modular Cloud — and the pace of internal iteration routinely outstripped what downstream projects could track.

The 1.0 stability policy borrows its model from mature systems languages, C++ being the explicit reference point. Within the 1.x line, changes are expected to be additive by default. Breaking changes remain possible, but Modular has committed to handling them the way a mature toolchain does: deliberately, with migration paths, rather than as routine release noise.

Importantly, "stable" in Mojo 1.0 does not mean "the entire standard library is frozen." Modular introduced a formal stabilization marker system with this release, and only a deliberately small initial set of APIs carries the full stability guarantee. Traits such as Deinitable, Movable, Copyable, and ImplicitlyCopyable are fully stable as of 1.0. Widely used types like Array, List, Span, String, Bool, and Optional have only some of their APIs marked stable so far — the rest remains subject to change in later 1.x releases. Developers building long-lived systems on Mojo need to check the stabilization marker on each API surface they depend on, not just the language version number.

There's a second, easily missed caveat: the stability guarantee currently covers source compatibility, not ABI compatibility. Binary compatibility across compiler versions is not yet promised, which matters if you're distributing precompiled Mojo libraries rather than recompiling from source on each release.

Because so much surface area was locked down in this release, 1.0 actually ships with more breaking changes than a typical Mojo release — the tradeoff Modular made deliberately to get names, defaults, and safety boundaries right before freezing them. Nearly every one of those breaking changes ships with a deprecated alias and an automated compiler fix-it, so most migrations are mechanical rather than requiring a manual audit of every call site.

Language-level changes worth knowing before you port code

Declaration and closure unification

Mojo has converged on a single way to declare a mutable binding. Where earlier versions allowed implicit declaration in some contexts — convenient, but a source of "typo silently becomes a new variable" bugs — 1.0 consistently requires var:

fn compute_mean(data: List[Float64]) -> Float64:
    var total: Float64 = 0.0
    var count = 0
    for value in data:
        total += value
        count += 1
    return total / count

Closures went through a parallel unification. The old unified keyword is gone. Capture semantics are now expressed with an explicit capture list {...} following the function signature; an empty {} denotes a unified closure with no captures, while omitting the capture list entirely marks a closure as legacy. Stateless closures now auto-lift to top-level functions and can be passed directly as FFI callbacks. A new thin function-pointer effect exists specifically for declaring a plain function pointer type that carries no captured state at all — useful when you're handing a callback to a C API that expects a bare function pointer.

Mojo 1.0 also adds real single-expression lambda syntax, closing a long-standing ergonomic gap for anyone translating Python code:

var doubled = [x * 2 for x in values]
var by_length = sorted(words, key=lambda w: len(w))

Under the hood, a lambda desugars to a nested def, so it's syntactic sugar rather than a distinct closure mechanism — but it removes the friction of writing a named nested function for every trivial callback.

Pointer unification and non-nullability by default

Pointer and UnsafePointer — previously two separate types with overlapping responsibilities — are now a single Pointer type. The change in philosophy is more significant than the rename: instead of marking an entire type as "unsafe," individual operations on a pointer are now marked unsafe at the call site. This gives the compiler and human reviewers a much more granular signal about where actual unsafety occurs in a codebase, rather than treating every use of a pointer type as equally risky.

The unification also removed pointer nullability as a default. The old pattern of a default-constructed null pointer is deprecated; Pointer no longer conforms to Defaultable or Boolable for this purpose. If a pointer genuinely needs to represent "no value," you now wrap it explicitly:

var maybe_ptr: Optional[Pointer[Int]] = None

if maybe_ptr:
    print(maybe_ptr.value()[])

Optional[Pointer[T]] reuses the null address as the None niche internally, so this wrapping costs nothing at runtime and remains layout-compatible with FFI code expecting a raw nullable pointer. UnsafeAnyOrigin, the escape hatch used to widen a reference's lifetime arbitrarily, is also harder to reach by accident now: implicit widening to it is deprecated, and a struct field can no longer silently hide one.

Collection semantics: bounds checking and the loss of negative indexing

Standard library collections are bounds-checked by default in 1.0, and — more disruptively for anyone porting Python — negative indexing has been removed entirely. x[-1] is now a compile-time error rather than "last element," and the idiomatic replacement is x[len(x) - 1].

This is a real source of breakage for Python-to-Mojo ports, and it's worth grepping for [-1] and [-N] patterns specifically before assuming a migrated module compiles cleanly. The rationale is consistent with Mojo's broader safety posture: implicit wraparound indexing is a common source of subtle bugs in array-heavy code, and the language would rather force an explicit expression than silently do something Python-programmer-intuitive but easy to get wrong at the boundaries.

A related but separate change: list literals like [1, 2, 3] now construct an Array by default rather than a List. Array is a fixed-size, stack-friendly container, while List remains the growable heap-backed type — so code that relied on list-literal syntax producing a resizable container needs to switch to an explicit List(...) constructor call.

Reference invalidation diagnostics and interior origins

The most consequential correctness feature in this release is compile-time detection of reference invalidation. Mojo's existing origin/lifetime checker already prevented references from outliving the value they point to; 1.0 extends that checking to catch a narrower and nastier class of bug — a reference into a container becoming invalid because a mutation on the same container reallocated its backing storage. The canonical example is holding a reference to an element of a List and then calling .append() on that same list in a way that could trigger a reallocation. Previously this was a silent dangling reference; the compiler now rejects it statically.

This is supported by an experimental capability called interior origins, which lets List, Dict, String, and a handful of other standard library types return element references whose origin is explicitly tied to the interior of the container, rather than treating the whole container as one undifferentiated origin. That distinction is what lets the checker reason about "this reference came from inside this specific container" instead of being forced to either over-approximate (reject too much valid code) or under-approximate (miss real bugs).

Smaller but real breaking changes

A number of narrower changes are easy to miss in a changelog skim but will surface immediately if your code touches them:

where clauses can now carry an optional string-literal diagnostic message — where(condition, "message") — which the compiler surfaces when the constraint fails, making generic code failures far more actionable than a bare constraint-violation error.
== and != now work for type equality checks directly.
Method self parameters must now have type Self; code that gave self a different declared type needs to move that logic into a where clause instead.
Overloads that differ only in argument convention (imm versus mut) are now rejected, since the compiler cannot resolve overload selection based on convention alone.
Reserved words (class, del, match, yield, and similar) can no longer be used as free function names. This previously produced a function that could never actually be called; it's now a declaration-time error.
The compiler tightened whitespace rules in specific spots — no newline is permitted between def/struct/trait/comptime and the following identifier, between async and def, or in the middle of an unparenthesized import statement.
Keyword variadics can now be forwarded from one function to another using Python-style ** syntax, closing a gap that made wrapping functions with many optional keyword arguments awkward. Individually these are small. Collectively, they're why Modular flagged this release as carrying more breaking changes than usual, and why the deprecated-alias-plus-fix-it approach matters: without it, adopting 1.0 on an existing several-thousand-line codebase would be a multi-day manual audit rather than a mostly-automated pass.

GPU and accelerator targeting

Mojo's differentiator has never really been "Python syntax" on its own — it's that the language compiles through MLIR rather than directly through LLVM. LLVM targets one hardware architecture at a time; MLIR is designed to let multiple levels of abstraction coexist in a single compilation pipeline, which is what allows the same Mojo source to be specialized for CPU, GPU, and other accelerator targets without hand-written per-vendor code paths. Modular has built a kernel-generation layer, internally referred to as KGEN, on top of MLIR specifically to represent parametric AI kernels before they're instantiated for a given hardware target. In practice, this is what lets a Mojo kernel target NVIDIA Tensor Cores, AMD matrix accelerators, and other accelerator hardware from one source file.

1.0 also clarifies the rules at the CPU/GPU boundary. Int and UInt use the host's native word size, which isn't guaranteed to match the device's — so when a value of type Int or UInt crosses into a GPU kernel, Mojo remaps it to the corresponding fixed-width type rather than leaving the width ambiguous. For code where the exact bit width matters at the register or memory-layout level — file formats, pixel buffers, hardware registers — the standard library guidance is still to reach for an explicit sized type yourself rather than relying on the remap:

fn kernel(n: Int32): ...

Some accelerator-specific APIs also moved out of core Mojo entirely and into a separate max package, with the layout module now living on the MAX side rather than in the language proper. This reflects a deliberate architectural split: Mojo is positioning itself as a general-purpose systems language, with MAX as the layer responsible for tensor-aware, kernel-aware, inference-serving concerns.

On the performance side, independent validation is available from a 2025 study by researchers at Oak Ridge National Laboratory, presented at the SC25 WACCPD workshop, where it received the Best Paper award. The study benchmarked Mojo GPU kernels against CUDA on an NVIDIA H100 and against HIP on an AMD MI300A, using real HPC science workloads rather than synthetic microbenchmarks. For memory-bound workloads — a stencil computation was the representative case — Mojo averaged approximately 87% of CUDA's throughput on the H100 in both single and double precision, with a somewhat larger gap at double precision. On the AMD MI300A, Mojo was broadly competitive for memory-bound work but showed a more pronounced gap for atomic operations and fast-math-heavy compute-bound workloads. The study's authors framed the result as evidence that Mojo's write-once, cross-vendor portability comes at a modest and workload-dependent cost relative to hand-tuned, vendor-specific code — notable given that the benchmarks were run against a pre-1.0 version of the language.

Python interoperability

Mojo is frequently described as "a superset of Python," but that framing has been explicitly walked back by Modular over the past year; the language is not source-compatible with Python 3 and does not aim to be. Mojo uses struct types with compile-time-determined layout rather than Python's dynamic class system, and it interoperates with Python code through the CPython runtime rather than by directly executing Python source. You cannot rename a .py file to .mojo and expect it to compile — the practical adoption model is writing new performance-critical code in Mojo while continuing to call into the existing Python ecosystem across a runtime bridge.

That bridge got measurably faster in this release. Arithmetic, comparison, and containment operations on PythonObject now go directly through CPython's abstract object protocols instead of a slower dispatch path, and Modular's own measurements show roughly a 12x improvement for call-boundary-heavy patterns like repeated a + b or a < b comparisons. It's worth being precise about what this number means: it is not a claim that Mojo code is 12x faster than equivalent Python — it's specifically the overhead of crossing the Mojo/CPython boundary shrinking for arithmetic-heavy interop patterns. For code with a hot loop that repeatedly touches Python objects from Mojo, this is a legitimate and measurable win; for code that stays entirely within Mojo-native types, it's not directly relevant.

Open source status

The Mojo standard library has been available under the Apache 2.0 license (with LLVM exceptions) since 2024. The compiler and toolchain were the remaining proprietary piece, and Modular had publicly committed to open-sourcing them by the end of 2026. That commitment was fulfilled within the past week: following ModCon, Modular's annual developer conference held August 18 in San Francisco, the compiler and toolchain were released under Apache 2.0 as well, closing the loop on a promise the company had made since Mojo's original 2023 launch.

This detail matters beyond ideology. Modular's acquisition by Qualcomm closed on July 28, 2026. Mojo's core value proposition to the AI infrastructure market has always rested on vendor neutrality — the claim that a Mojo kernel targeting NVIDIA hardware and one targeting AMD hardware get equally serious compiler treatment. That claim is harder to simply trust once the compiler is owned by a company that also designs its own accelerator silicon. An open-source compiler doesn't eliminate that concern, but it does convert an unverifiable promise into one the community can audit directly by inspecting how code generation actually treats each hardware backend.

What's still missing

Mojo 1.0 is explicitly not a claim that the language is feature-complete. Three capabilities called out on Modular's own roadmap remain absent: a mature asynchronous programming model (async/await exists in a limited form, but a full async runtime story is still forthcoming), pattern matching, and union types. Teams whose workloads are concurrency-heavy rather than compute-heavy — network services doing a lot of concurrent I/O, for instance — will feel these gaps directly; Mojo's current strengths are firmly on the CPU/GPU-bound compute side of the spectrum, not on the async-service side.

The library ecosystem is real but still young relative to Python's or Rust's. Community-maintained projects exist and are actively developed — an HTTP framework called Lightbug, a pure-Mojo JSON library called EmberJSON, and a type-safe dimensional-analysis library called Kelvin are three commonly cited examples — but developers evaluating Mojo for a given task should expect to write more of their own supporting infrastructure than they would in a decade-old ecosystem.

Practical guidance for adoption

Upgrading is a one-line operation:

uv pip install --upgrade mojo
uv pip install max[all]

Before migrating an existing codebase, it's worth budgeting specific time for three mechanical sweeps rather than assuming the compiler's deprecated-alias fix-its catch everything silently: a search for negative indexing patterns ([-1], [-2], etc.), a check of any list-literal usage that assumed a growable List rather than a fixed-size Array, and a review of pointer-handling code that relied on default-null construction or implicit Boolable checks on Pointer/UnsafePointer. None of these are large individually, but they're the changes most likely to produce a compile error that isn't automatically resolved by the compiler's suggested fix.

For teams evaluating whether to adopt Mojo now versus waiting: the 1.0 stability guarantee is real for APIs explicitly marked stable, and the combination of MLIR-based cross-vendor GPU targeting with an open-source compiler is a genuinely distinctive position in the current AI infrastructure stack. The clearest fit today is numeric or tensor-heavy code that needs to target multiple accelerator vendors without maintaining separate CUDA and ROCm code paths, or performance-critical inner loops embedded in an otherwise Python-based system, where a full rewrite into C++ or Rust would be disproportionate to the problem. Teams that need async-heavy concurrency, pattern matching, or a deep third-party package ecosystem comparable to PyPI or crates.io should treat those as open gaps rather than assumptions, and plan accordingly.

For more such in-depth developer content, visit:
https://vickybytes.com

A Complete Guide to GitHub Stacked PRs

Shrestha Pandey — Wed, 12 Aug 2026 12:36:46 +0000

You know that feeling when you spend three days building a feature. You open a pull request and it's 1,200 lines long. Your teammate sees it, and says, "I'll review this later." That later becomes tomorrow. Tomorrow becomes next week. Meanwhile, main moves on, conflicts appear, and your "small feature" turns into a mini-project.

There's a better way, and it's called stacked PRs. GitHub now supports it natively, in public preview as of July 30, 2026, rolling out to all repositories. This article explains it in plain language.

Current status: Stacked PRs are in public preview. The core feature (creating stacks, reviewing each layer, merging in one click) works today. Merge queue support is rolling out separately over the following weeks, so if your repo relies on a merge queue, double-check compatibility before betting a workflow on it.

The Problem: One Giant PR That No One Wants to Review

Imagine you're adding a new feature: "User preferences."

To make it work, you need to:

Add a new database table
Create API endpoints
Build a settings page in the UI

If you do all of this in one branch and open one PR, you get:

A huge diff that's hard to understand
Reviewers who don't know where to start
Long wait times and painful merge conflicts

This is the "monster PR" problem, which slows everyone down.

The Idea: Break the Feature Into Layers

Instead of one giant change, think in layers:

Layer 1 – Database: Add the user_preferences table and migration.
Layer 2 – API: Add endpoints to read and update preferences.
Layer 3 – UI: Add the settings page that calls those endpoints.

Each layer is small, focused, and easy to review. You still build the full feature, but you split the work into three smaller pull requests that build on top of each other. That's a stack.

Each PR's base is the branch below it, not main. GitHub shows this as a stack map at the top of the pull request, so reviewers can see how the change they're looking at fits into the larger work.

Why This Is Worth It

Stacked PRs solve real problems:

Faster reviews: A 200-line PR gets reviewed much faster than a 1,200-line PR.
Less pain when merging: Smaller PRs mean fewer conflicts and easier rebases.
You can ship incrementally: Once the DB PR is approved, you can merge it while still working on the UI.
GitHub now supports it natively: As of July 30, 2026 this is built into the pull request workflow itself — no third-party tooling required to get the basic experience. If your team complains about slow reviews or giant PRs, this is a practical fix.

Step-by-Step: Your First Stacked PR

Let's walk through a real example. We'll use the "User preferences" feature with three layers: DB, API, UI.

You only need:

Git installed
GitHub CLI (gh) installed
A repo with stacked PRs enabled (it's rolling out progressively, so check it's available on yours)

Step 1: Install the gh-stack extension

gh extension install github/gh-stack

Check it's installed:

gh stack --help

If you see help text, you're good.

Step 2: Start From main

git checkout main
git pull

Step 3: Create the First Layer (Database)

gh stack init feat/prefs-db

This creates a new branch feat/prefs-db from main and starts a new stack.

Now make your database changes: add the migration file, update models, run tests. Then commit:

git add .
git commit -m "Add user_preferences table and migration"

At this point, you have one branch with one logical change.

Step 4: Add the Second Layer (API)

From the DB branch, add the next layer:

gh stack add feat/prefs-api

This creates feat/prefs-api on top of feat/prefs-db and keeps the stack structure.

Implement the API: add controller/routes, GET /preferences and PUT /preferences, add tests.

Commit:

git add .
git commit -m "Add preferences API endpoints"

Now you have two layers: DB → API.

Step 5: Add the Third Layer (UI)

gh stack add feat/prefs-ui

You're now on feat/prefs-ui, sitting on feat/prefs-api, sitting on feat/prefs-db, sitting on main.

Implement the UI: settings page component, connect to the API, handle loading and error states.

Commit:

git add .
git commit -m "Add user preferences UI"

You now have three layers ready.

Step 6: Push the Whole Stack to GitHub

From the top branch (feat/prefs-ui), run:

gh stack submit

This command pushes all three branches in the right order and creates three pull requests:

PR1: feat/prefs-db → main
PR2: feat/prefs-api → feat/prefs-db
PR3: feat/prefs-ui → feat/prefs-api It links them together as a stack in the GitHub UI. Open any of these PRs and you'll see a stack map showing "this PR is part of a stack" with links to the PRs above and below. Reviewers see the full story, but each PR shows only its own changes.

How Reviewers See It

Without stacked PRs:

one PR, 1,200 lines, touching DB, API, and UI. The reviewer doesn't know where to start and leaves a vague comment: "This is huge, can we split it?"

With stacked PRs:

PR1 (DB): 150 lines, just schema and migration. "Is the table correct? Is the migration safe?"
PR2 (API): 200 lines, just endpoints. "Are routes correct? Auth in place? Tests passing?"
PR3 (UI): 250 lines, just frontend. "Does the UI match the design? Error handling okay?" Each PR is focused. Each review takes 10–15 minutes instead of an hour. That's the whole point.

What Happens When You Need to Change Something?

Say the reviewer asks you to add an index to the user_preferences table (DB layer), plus one more API validation.

Fix the DB branch:

git checkout feat/prefs-db
# edit migration, add index
git add .
git commit -m "Add index on user_id"

Rebase the layers above. Rather than rebasing each branch by hand, use the CLI's built-in cascade rebase, which rebases every branch in the stack onto its updated parent in one step:

gh stack rebase

If a conflict comes up, gh stack rebase walks you through resolving it branch by branch and restores everything to a clean state if you abort.

Update the stack on GitHub:

gh stack push
gh stack submit

gh stack push pushes the rebased branches (force-with-lease where needed), and gh stack submit updates the existing PRs and keeps the stack links intact. Reviewers see your new commits in the right PRs.

Yes, there's rebasing. But:

You're rebasing small, focused branches (easier than one giant branch)
You do this often, so it becomes routine
The CLI's cascade rebase handles the heavy lifting instead of you doing it branch-by-branch

Merging: You Don't Have to Wait for Everything to Be Done

One of the best parts: you can merge layer by layer.

PR1 (DB) is approved and CI is green → merge it.
PR2 (API) and PR3 (UI) stay open while you keep working.
After PR1 merges, the branches above it automatically rebase and retarget onto the updated main.
Later, PR2 gets approved → merge. Then PR3 → merge. By default, merging the topmost ready PR in a stack lands that PR and every unmerged layer below it in a single operation — you don't need to enable anything special for this. Your existing branch protections and required checks still govern what actually reaches main.

Real Example: From "Monster PR" to Three Small PRs

Before: One Big PR

Branch: feat/user-preferences

Migration + models: ~200 lines
API endpoints + tests: ~350 lines
UI components + styles + tests: ~650 lines Total: ~1,200 lines in one PR. The reviewer doesn't know where to start, requests changes on tangled code, and keeps pushing the review off. The PR sits for days, conflicts appear, morale drops.

After: Three Stacked PRs

PR1 – DB (feat/prefs-db): migration + basic model + validation tests. ~150 lines. Focus: "Is the schema right? Is the migration safe?"
PR2 – API (feat/prefs-api): controller + routes, auth checks, input validation, API tests. ~250 lines. Focus: "Are endpoints correct and secure?"
PR3 – UI (feat/prefs-ui): settings page, API integration, loading/error states, E2E tests. ~300 lines. Focus: "Does the UX match the spec?" Each reviewer sees a clear, focused job. Reviews happen faster. You get feedback sooner and merge sooner.

Common Questions (Answered Simply)

Isn't this more work?

Upfront, yes — more branches, more PRs. But each PR is easier to create (smaller diff, clearer description), each review is faster, and you spend less time resolving massive merge conflicts later. For anything beyond a tiny change, stacked PRs usually save time overall.

What about CI? Won't tests fail on higher PRs?

Each PR runs CI against its base branch: PR1 (DB) runs on main, PR2 (API) runs on feat/prefs-db, PR3 (UI) runs on feat/prefs-api. Some checks might only fully pass once lower PRs are merged — that's expected. Make sure required checks are green on each PR's base, and note in your PR template that some checks depend on lower layers.

When should I not use stacked PRs?

Avoid them when the change is tiny (a single 100-line PR is fine), when the layers are too tightly coupled to review separately, or when your team is still getting comfortable with basic Git branching and rebasing.

Use them when the feature naturally splits into layers (DB/API/UI, core/extension/integration), reviews are slow because PRs are too big, and your team is comfortable with rebase-based workflows.

Mistakes People Make (and How to Avoid Them)

Too many layers. Don't turn a small feature into 10 tiny PRs. 2–5 PRs per feature is usually right; if you need more, the feature itself may be too big.
Unclear descriptions. Reviewers shouldn't have to guess what a PR does or where it sits in the stack. Say what it does, what it depends on, and what follows it.
Ignoring the bottom PR. The bottom PR is the foundation — if it's messy, everything above it is shaky. Keep it clean, well-tested, and understandable on its own.
Being afraid of rebase. You'll rebase more, but each rebase is smaller, you get good at it fast, and gh stack rebase reduces the manual work significantly. ## A Simple Checklist Before You Push

Before you run gh stack submit, ask:

Does each PR have one clear purpose?
Can someone understand the bottom PR without seeing the others?
Are branch names clear (e.g., prefs-db, prefs-api, prefs-ui)?
Did you mention the stack in each PR description?
Are tests passing locally on each layer?
If your repo uses a merge queue, have you confirmed stacked-PR support is available yet?

If yes, you're ready.

TL;DR (For Your Next Feature)

Don't send one giant PR.
Split your feature into 2–4 logical layers.
Use gh stack (native to GitHub as of the July 2026 public preview) to create a stack of PRs.
Let reviewers focus on small, clear diffs.
Merge layer by layer, reduce conflicts, and ship faster.

How MCP Works And Why Agents Use It

Shrestha Pandey — Sun, 09 Aug 2026 06:17:28 +0000

Every few years, a problem gets solved, and the whole industry moves faster. USB-C did this for chargers. REST did this for web APIs. In late 2024, Anthropic built something similar for AI. It's called the Model Context Protocol, or MCP.

The problem was, an AI model needs to use outside tools like your database, your email, your project tracker, but every tool is different, every AI app is different. Without a shared standard, someone has to build a custom bridge for every single pair.

MCP is that shared standard. This article explains how it works, piece by piece. We'll also cover the newest version of MCP, called 2026-07-28. It came out just a few days ago, and it changed a lot of things. So if you read about MCP before, some of it is now out of date. This article covers both the old way and the new way.

1. The problem MCP solves

Before MCP, connecting an AI to a tool meant writing custom code. That code had to talk to the tool's API. It also had to match whatever format the AI model needed. If you switched to a different AI model, you often had to rewrite that code.

Let's say you have N different AI apps. Maybe that's Claude Desktop, a coding assistant, and a Slack bot. And you have M different tools they need to use. Maybe that's GitHub, a database, and Jira. Without a shared standard, you need custom code for every single pairing. That's N × M pieces of code. It grows fast.

MCP fixes this. Each tool only needs to build one MCP server. Each AI app only needs to build one MCP client. Now any app can talk to any tool, because they all speak the same protocol. That turns N × M pieces of code into just N + M.

Code editors solved the same kind of problem years ago with something called LSP (Language Server Protocol). MCP borrowed that same idea and built on it.

2. What MCP is

MCP is not an app. It's not a tool you install and run. It's a set of rules for how messages get sent back and forth. Under the hood, it uses a simple message format called JSON-RPC. On top of that, MCP adds a few building blocks made just for AI: tools, resources, and prompts. We'll explain those soon.

There are always three parts involved:

Host — the app the person is actually using. This could be Claude Desktop, a coding tool, or your own app. The host holds the AI model and the conversation. It also decides what is allowed to happen. If a tool wants to do something risky, the host is what can stop it or ask for approval.
Client — a small connector that lives inside the host. There's one client for every server it talks to. If the host connects to five different tools, it runs five clients. The client's job is simple: pass messages back and forth. It doesn't make decisions on its own.
Server — the thing that actually offers tools or data. Most servers are simple wrappers around something that already exists, like an API or a database. The server doesn't know or care which AI model is using it.

The key point is, the AI model never talks to the server directly. The host always sits in the middle. When a tool sends back a result, the host is the one that adds it to the conversation. This matters a lot. It means the host can check things, ask the person for approval, or block something risky before it happens.

3. How the messages actually travel

MCP supports two main ways to send messages:

stdio — the server runs as a small program right on your computer. Messages are just plain text, sent back and forth. This is the easiest option, and it's what most "install this on your laptop" guides use. There's no network involved, so it's simple and safe by default.

Streamable HTTP — this is used when the server lives somewhere else, like a company's cloud server. The client sends a request over the internet, and the server sends back a reply. Sometimes the reply comes all at once. Sometimes it streams back a little at a time. This is the option used for tools that many people share, not just one person on one laptop.

Starting with the newest version of MCP, every HTTP message also includes two extra pieces of information in its header: which method is being called, and which tool it's for. It means a company's security system can check and control requests just by reading these two header values. It doesn't need to open up and read the entire message first.

POST /mcp HTTP/1.1
Host: api.example-mcp.com
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{"jsonrpc":"2.0","id":42,"method":"tools/call",
 "params":{"name":"create_issue","arguments":{"title":"Bug: nav bar overflow"}}}

4. The "handshake" that used to be required

If you read an older MCP guide, it starts with something called a handshake. The client says hello first, and tells the server what it can do. The server replies, and says what it can do. Then the client says "okay, we're ready." The server would also give the client a special ID number, and the client had to include that ID on every single message after that, so the server would remember who it was talking to.

This worked fine when the server was just a small program on your own computer, but it caused real problems for servers running in the cloud, shared by lots of people. The server had to remember which person was "who," and every request from that person had to be routed back to the exact same server machine.

The newest version of MCP removes all of this. There's no more hello message, and no more special ID to remember. Every single message now carries everything it needs, all on its own. Because of this, any message can be handled by any available server machine. If a client really wants to know what a server can do ahead of time, it can still ask, but it's optional now.

But if a tool genuinely needs to remember something between steps, the tool hands back a kind of "ticket" or reference number, and the AI model passes that ticket back on the next request. The memory lives in the conversation itself, where everyone can see it.

5. The building blocks a server can offer

MCP only allows a server to offer a few specific kinds of things. Keeping this list short and simple makes it much easier for both AI models and apps to understand what's happening.

Building block	Who starts it	Who allows it	What it's for
Tools	The AI model decides to call it	The host decides if it's allowed	Doing something: sending an email, running a search, creating a ticket
Resources	The app decides to use it	The app decides if it's allowed	Reading something: a file, a database row, a log
Prompts	The person picks it directly	The person chooses it	A ready-made template, like a saved shortcut
Sampling (being phased out)	The server asks for it	—	The server asks the AI model to write something mid-task
Roots (being phased out)	The client tells the server	—	Telling a server which folders it's allowed to touch

A tool is described with a name, a short explanation of what it does, and a list of the information it needs:

{
  "name": "create_issue",
  "description": "Create a new issue in the project's issue tracker.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "body": { "type": "string" },
      "labels": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["title"]
  }
}

6. How a server can still ask you something, even without memory

Sometimes a tool needs to check with you before it finishes. Maybe it wants to confirm something risky, like "are you sure you want to delete this?" But we just said servers don't remember anything between messages anymore. So how does that work?

The answer is called MRTR, short for Multi Round-Trip Requests. Instead of the server waiting and holding the line open, it just replies right away and says "I need more information first."

There's no open connection the whole time. The client just asks the same question again, this time with the answer included. This is simple, and it works well even though the server has no memory at all.

7. A full tool call, from start to finish

Let's walk through one complete example.

1. The host prepares the available tools. It already knows which tools the server offers and converts them into the format the AI model expects.

2. The AI model decides to call a tool. It chooses create_issue and fills in the required arguments.

3. The client sends the request:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue
Authorization: Bearer eyJhbGciOi...

{"jsonrpc":"2.0","id":17,"method":"tools/call",
 "params":{
   "name":"create_issue",
   "arguments":{"title":"Bug: nav bar overflow","labels":["frontend"]}
 }}

4. The server does the real work by creating the issue and returning the result.

{"jsonrpc":"2.0","id":17,"result":{
  "resultType":"success",
  "content":[{"type":"text","text":"Created issue #4821: Bug: nav bar overflow"}],
  "structuredContent":{"issueId":4821,"url":"https://tracker.example.com/issues/4821"}
}}

5. The host adds the result back into the conversation. The AI model now knows the issue was created and continues its reasoning.

That's the whole loop: model, host, client, server, and the real tool being used. This repeats as many times as needed until the AI model has everything it needs to answer.

8. Why AI agents need this

You might ask: why not just give the AI model direct access to a normal API? People tried that in the early days, but it ran into real problems:

Every AI model expects a slightly different format. With MCP, the tool only needs to describe itself once. Each app then translates that into whatever format its own AI model needs. The tool author doesn't need to learn the details of every AI model out there.

Tools need to be discovered on the fly. An AI agent often doesn't know ahead of time which tools it will need. Being able to ask "what tools do you have?" at any time, and get a clear answer, matters a lot.

Reading data and taking action are very different things, and mixing them up is dangerous. MCP keeps them separate on purpose. Reading a file is treated differently than deleting one. This lets the host set a simple, clear rule: reading things can happen quietly, but taking action needs a check first.

Someone needs to enforce the rules in one place. If every tool has its own custom code, safety checks can easily get missed somewhere. With MCP, every single tool call passes through the same host, so the same safety rules apply every time, no matter which tool is being used.

Not needing memory matches how these systems are actually used. A company might have thousands of people using an agent at the same time, hitting many different tools. Not needing to remember each person's exact connection makes this much easier to run at a large scale.

9. Trust and safety: what can go wrong, and how MCP handles it

This is one of the most important parts, and it's often skipped in simple guides.

MCP treats three sides as possibly untrustworthy toward each other: the person, the AI model and host, and the server. That might sound harsh, but here's why it matters:

A bad server could try to trick the AI model. A tool's description is just text, and that text becomes part of what the AI model reads. A dishonest tool could hide sneaky instructions inside its own description, hoping the AI model follows them without the person knowing. This is called prompt injection. The lesson: never fully trust text that comes from a tool, the same way you wouldn't fully trust a random file someone sent you.

A careless client could give a tool too much power. If an app hands over a very powerful access key without limiting what it's for, and something goes wrong, the damage could be much bigger than it needed to be. The fix is simple: always give tools the smallest amount of access they actually need, nothing more.

Never blindly pass one access key to a different tool than it was meant for. This sounds obvious, but it's a common mistake. The newest version of MCP adds stronger checks around this, making sure access keys are only used exactly where they were meant to be used.

The newest version also improves how login and access approval work, closing a few tricky security gaps that experts had found. The overall advice stays the same as always: give every tool the smallest access it needs, don't trust text from a server blindly, and keep a person in the loop for anything risky or hard to undo.

10. How MCP grows without breaking older tools

The newest version also introduces a cleaner way for MCP to grow over time. Instead of stuffing every new idea into the core rules, new features can now be added as separate, optional "extensions." Each one has its own name and its own version number, so it can grow and change without breaking everything else.

Two extensions launched alongside this update:

MCP Apps — lets a tool show an actual visual interface, not just text, inside a safe, boxed-off area of the app. Even though it looks different, anything the person does inside that interface still follows the exact same safety and approval rules as a normal tool call.
Tasks — built for work that takes a long time to finish, like a big data job. Instead of waiting the whole time, the app can check back later to see if it's done.

The bigger idea here is, keep the core of MCP small and simple, and let fancier features grow on the outside, as optional add-ons. This is a common pattern in long-lasting technology.

11. Where MCP is heading next

MCP is moving toward a smaller core protocol with optional extensions. Enterprise management, long-running tasks, and newer capabilities are being built as add-ons instead of becoming part of the core standard.

Older features that are being phased out will continue working for at least a year, giving developers time to migrate. At the same time, support for MCP has grown quickly across the industry, making it increasingly likely to become the standard way AI applications connect to external tools.

The short version

MCP is a shared standard that lets AI apps and outside tools talk to each other safely. It has three parts: the host (which runs the AI model and enforces the rules), the client (a simple messenger), and the server (which offers tools, data, or templates). The newest version removed the need for servers to remember anything between messages, which makes everything easier to run at a large scale. It also added a smart way for tools to ask for confirmation without needing to stay connected the whole time. AI agents need something like MCP because they must discover tools on the fly, keep reading and doing separate, and never fully trust anything a tool sends back without checking it first.

For more such developer content on multiple formats, visit:
https://vickybytes.com

Complete Guide to Context Engineering in LLMs

Shrestha Pandey — Sun, 02 Aug 2026 07:14:02 +0000

Context engineering is one of those terms that you understand when you actually build with LLMs in production. Then it becomes clear that this is the real work of deciding what information the model should see, how that information should be arranged, what should be remembered, what should be retrieved, and what should be kept out of the window entirely. This brings most of the quality improvements in 2026.

For a long time, LLM output quality was treated as a prompt-writing problem, which was true to a certain point when the use cases were simple and the conversations were short. But once LLMs started powering agents, coding assistants, research workflows, and copilots, the old prompt-first mindset began to break. More often, the model had the wrong context, too much context, stale context, or context arranged in a way that made it hard to use. That is the problem context engineering tries to solve.

What context engineering means

Context engineering is the discipline of shaping the full information payload around an LLM at inference time. The payload includes system instructions, user input, retrieved documents, memory, tool outputs, schemas, summaries, and the conversational history. In other words, the model is reasoning inside a temporary workspace, and the quality of that workspace heavily affects the answer it gives.

Prompt engineering changes how you ask the model a question, while context engineering changes what the model knows when it answers. A well-written prompt can still fail if the model is missing the relevant facts, overloaded with noise, or forced to reason over stale memories and irrelevant tool outputs.

Why it matters now

The reason this topic has exploded in 2026 is that LLM applications are now systems, they read files, call tools, search databases, remember prior state, execute multi-step workflows, and sometimes even hand work off to other agents. As soon as you move into that world, the biggest source of failure becomes context management, not prompting.

This is especially visible in long-horizon agents. If an agent is working for many steps, it creates its own history, accumulates its own tool results, and gradually fills the window with decisions, partial outputs, and summaries. Without intentional context control, the model starts to lose track of what’s important. Anthropic’s agent guidance for long-running systems highlights this problem and points to compaction, structured notes, and careful memory handling as practical solutions.

The four pillars

A useful way to organize context engineering is around four connected actions: write, select, compress, and isolate. This framework captures the full lifecycle of context rather than just the initial prompt.

Write means storing durable information outside the active window. If something should survive beyond the current turn, it should not live only in chat history. User preferences, task checkpoints, important decisions, stable project facts, and reusable notes all belong in a more persistent store. That can be a memory system, a database, a file, or any structured state layer.

Select means retrieving only what is relevant for the current step. This is where RAG, semantic search, code search, and memory retrieval matter. Good selection is all about finding the smallest set of evidence that is enough to support the task.

Compress means reducing context size without losing meaning. This usually involves summaries, pruning old tool outputs, shortening long conversations, and representing repeated information in compact form. Compression is what keeps a system usable after the first few steps.

Isolate means separating tasks so they do not corrupt each other. A planning context should not be mixed with execution noise. Untrusted text should not sit in the same place as trusted instructions. Different agents or stages should be kept distinct when the workflow gets complicated.

How a production pipeline works

In production, context engineering usually looks more like pipeline design. The user request enters the system, then the app classifies the task, fetches relevant sources, trims and ranks them, strips out unnecessary content, adds the minimum required instructions and tool definitions, and then makes the model call. After the call, useful outputs are stored externally so they can be reused later without bloating the live context.

That pipeline is easy to describe, but many teams still skip parts of it. They either retrieve too much and drown the model in text, or retrieve too little and leave it guessing. The best systems tend to be aggressively selective. They trust structure over volume.

Where systems go wrong

The most common mistake is assuming more context automatically means better answers. In practice, that often creates the opposite effect. Long windows can degrade when the context is noisy, poorly ordered, stale, or full of redundant material. The model may technically have the information, but it may not use it well.

Another classic failure is weak retrieval. If the right facts exist somewhere but are not brought into the window at the right time, the model will improvise. This can be dangerous in coding, research, support, or agent workflows where correctness matters. Tool output has the same problem, if it is not integrated cleanly, the model may ignore it or overvalue it.

A third issue is context pollution. Once irrelevant text is mixed into the working set, the model can treat it as if it matters. This is why untrusted content, especially retrieved text or user-provided documents, has to be handled carefully. It is not enough to fetch information; you also need to control how that information is presented.

What works

The same techniques appear in most practical 2026 guides. Using clear sections for instructions, background, and expected output helps the model understand what each part is for. Short summaries of earlier messages keep important context without including the entire conversation. Breaking information into smaller, relevant chunks makes retrieval more accurate and avoids unnecessary text. Caching also saves time and cost by reusing prompts or templates that do not change.

The key idea is that more context is not always better. The best context gives the model only the information it needs to complete the task correctly. This may seem simple, but it actually improves performance. Leaving out unnecessary details reduces distractions and helps the model focus on the most relevant information.

For agents and coding assistants

This becomes very clear in agentic systems and coding tools. A coding assistant does not need your entire repository in the window to help you fix one bug. It needs the right files, the relevant symbols, the recent diffs, the related tests, and a bit of project-level convention. Good context engineering is about providing exactly the information needed for the task.

The same idea applies to AI agents that work over long periods. They need ways to save progress, organize memory, compress old information, and separate long-term knowledge from temporary working notes. Recent guidance, including Anthropic's recommendations and other 2026 resources, supports this more structured approach, where the system actively manages context over time instead of treating it as one large block of information.

The 2026 mindset shift

The biggest shift in 2026 is that context engineering is now seen as a complete system design practice. It combines prompt design, retrieval, memory management, tool integration, and state management to help AI models perform reliably. As a result, newer concepts such as retrieval budgeting, context compaction, memory tiering, tool-result pruning, and context isolation have become important parts of modern AI system design.

At the same time, the field is becoming more realistic about the limits of large context windows. While larger context windows are useful, they do not automatically improve results. The real challenge is selecting and managing the right information instead of simply providing more of it. This is why improving LLM performance is increasingly seen as a systems engineering problem during inference, rather than relying only on building larger models.

Final thought

If prompt engineering was about wording, context engineering is about design. It asks a harder question: what should the model know right now, and what is the cleanest possible way to make that knowledge available? Once you start thinking in this way, a lot of LLM failures start to look like ordinary information architecture problems. And that is good news, because information architecture is something that engineers can actually improve.

For more such developer content, visit:
https://vickybytes.com

My First End-to-End Data Pipeline in Databricks

Shrestha Pandey — Fri, 24 Jul 2026 13:40:50 +0000

Whenever I searched for resources on Databricks, I found two extremes. Some explained the concepts without showing how they fit together, while others jumped straight into large projects assuming you already knew the basics, but I wanted something in the middle.

Rather than learning every feature separately, I decided to build a small end-to-end project that covered the fundamentals of data engineering in Databricks. I wanted to understand how data moves through the platform, how different components connect, and why concepts like Delta Lake and the Medallion Architecture are used so often.

For this project, I used three simple retail datasets containing customers, products, and orders. Starting with these CSV files, I built a pipeline that reads the data using PySpark, stores it in Delta Lake, organizes it into Bronze, Silver, and Gold layers, analyzes it with Spark SQL, creates a dashboard, and finally automates the entire workflow using Databricks Jobs.

If you're just getting started with Databricks, this project covers many of the concepts you'll use in real-world workflows while keeping the implementation simple enough to follow.

Why Databricks?

Before starting with code, I explored the Databricks workspace to understand what the platform offers. The interesting part was how everything required for a data engineering workflow is available in one place.

The Workspace is where notebooks live, the Catalog helps organize data assets, the SQL Editor is used for writing analytical queries, and Jobs allows notebooks to run automatically on a schedule. Having these components integrated into a single platform makes it much easier to move from raw data to analytics without switching between multiple tools.

Another concept that appears everywhere in Databricks is the Lakehouse Architecture. Raw data needs to be stored safely, transformed into cleaner datasets, and eventually prepared for reporting or dashboards. The Lakehouse approach supports all these stages while using Delta Lake as the storage layer, which brings features like reliable transactions and version history.

This project follows that same approach from start to finish, which makes it easier to understand why the Lakehouse architecture has become a common choice for modern data engineering.

Setting Up the Environment

For development, I used a Databricks Notebook and uploaded my datasets into a Databricks Volume. I used Python and PySpark for data ingestion and transformations, switched to SQL for analysis, and added Markdown cells to organize different sections of the notebook.

The datasets were uploaded into a Databricks Volume, making them easy to access from the notebook.

The project uses three CSV files:

customers.csv
orders.csv
products.csv

Keeping the dataset small made it much easier to focus on understanding the workflow rather than spending time cleaning complex data.

Building the Data Pipeline with PySpark

With the environment ready, the next step was reading the datasets into Databricks using PySpark. Since the files were already uploaded to a Volume, accessing them from the notebook was simple.

customers = spark.read.csv(
    "/Volumes/workspace/default/retail_data/customers.csv",
    header=True,
    inferSchema=True
)

orders = spark.read.csv(
    "/Volumes/workspace/default/retail_data/orders.csv",
    header=True,
    inferSchema=True
)

products = spark.read.csv(
    "/Volumes/workspace/default/retail_data/products.csv",
    header=True,
    inferSchema=True
)

PySpark automatically inferred the schema, so I didn't have to manually define the data types for every column. After loading each dataset, I used display() to verify that everything had been imported correctly before moving on to transformations.

Storing the Raw Data with Delta Lake

Once the CSV files were loaded, I converted them into Delta tables. This was the beginning of the Bronze layer in the Medallion Architecture.

customers.write.mode("overwrite").format("delta").saveAsTable("bronze_customers")

orders.write.mode("overwrite").format("delta").saveAsTable("bronze_orders")

products.write.mode("overwrite").format("delta").saveAsTable("bronze_products")

The Bronze layer stores the data exactly as it arrives. At this stage, no cleaning or transformations are applied because it's useful to preserve the original data for auditing, debugging, or reprocessing later.

Cleaning the Data in the Silver Layer

To create the Silver layer, I performed some simple transformations on the orders dataset. For this, I removed duplicate records and filled missing values.

silver_orders = (
    bronze_orders
    .dropDuplicates()
    .na.fill({"quantity": 1})
)

The cleaned dataset was then stored as another Delta table. This stage represents a common pattern in data engineering. Cleaning and validating data before using it for analysis helps improve the reliability of downstream reports and dashboards.

Creating the Gold Layer

The final step in the transformation process was creating a dataset that could be used directly for analysis. I joined the customer, product, and order tables into a single DataFrame and calculated the revenue for each order.

from pyspark.sql.functions import col

gold_sales = (
    silver_orders
    .join(bronze_customers, "customer_id")
    .join(bronze_products, "product_id")
    .withColumn("revenue", col("price") * col("quantity"))
)

Finally, I saved the result as a Delta table.

gold_sales.write.mode("overwrite") \
    .format("delta") \
    .saveAsTable("gold_sales")

At this point, raw CSV files gradually turned into a structured dataset that could answer business questions with just a few SQL queries. It also demonstrated how PySpark and Delta Lake work together. PySpark handled the transformations, while Delta Lake provided a reliable storage layer for every stage of the pipeline.

Querying the Data with Spark SQL

Once the Gold table got ready, I switched to SQL to explore the data. It was really feasible to move between PySpark and SQL. Transforming data with PySpark felt simpler, while SQL made it simple to answer business questions without writing additional Python code.

For this project, I used the Databricks SQL Editor and a SQL Warehouse to run analytical queries. SQL Warehouses are optimized for interactive queries and reporting workloads, making them a good choice when exploring datasets or building dashboards.

I started with: Which products generated the highest revenue?

SELECT
product_name,
SUM(revenue) AS total_revenue
FROM gold_sales
GROUP BY product_name
ORDER BY total_revenue DESC;

The result highlighted the products contributing the most revenue.

Creating a Dashboard

After running the query, I created a simple bar chart directly within Databricks. The dashboard visualized revenue by product, making the results much easier to interpret than reading rows in a table.

Databricks lets you create charts from SQL query results in just a few clicks, which is useful for quickly sharing insights with teammates or stakeholders.

Automating the Pipeline with Databricks Jobs

Running a notebook manually is useful during development, though production pipelines usually need to execute on a schedule.

To complete the workflow, I created a Databricks Job for my notebook. The setup involved selecting the notebook, attaching the compute resource, and defining a schedule. Databricks also provides options for retries and notifications, making it easier to monitor automated workloads as projects become more complex.

Exploring Delta Time Travel

One feature I wanted to try before finishing the project was Delta Time Travel. Every change made to a Delta table is recorded, allowing previous versions to be inspected whenever required.

I viewed the history of my Gold table using:

DESCRIBE HISTORY gold_sales;

This feature can be especially useful when debugging pipelines or recovering from accidental updates.

A Quick Look at Unity Catalog

Since all my tables were created inside Databricks, I also explored Unity Catalog, which serves as the central place for managing data assets. It organizes tables, volumes, and other resources, making them easier to discover and manage across projects.

While this project focused on the fundamentals, Unity Catalog also supports governance features such as permissions and data lineage, which become increasingly important in collaborative environments.

What I Learned

Starting with raw CSV files and gradually moving through Bronze, Silver, and Gold layers showed how data evolves before reaching analysts or dashboards. PySpark handled the transformations, Delta Lake provided a reliable storage layer, SQL made analysis simpler, and Databricks Jobs completed the workflow by automating the notebook.

The project is small, but it covers many of the core ideas you'll encounter while working with Databricks. It helped me understand why these concepts exist rather than simply memorizing their definitions.

If you're getting started with Databricks, I'd recommend building a similar end-to-end project. It doesn't require a large dataset, and you'll come away with a much clearer understanding of how the platform works.

GitHub Repository

The complete notebook, datasets, and project files are available here:

🔗 GitHub: Databricks-pipeline

If you build on top of this project or have suggestions for improving the pipeline, I'd love to hear your thoughts.

For more such project ideas, visit:
https://vickybytes.com

The Debugger Is Lying to You Sometimes

Shrestha Pandey — Tue, 21 Jul 2026 20:46:07 +0000

Debugging should feel like the safest part of programming. Sometimes it does, but sometimes the debugger makes everything look fine while the real bug is hiding somewhere else, which is one of the most frustrating parts of development.

Everything looks correct, still the app breaks. This happens because the debugger only shows one moment in time. Software keeps moving, values change, requests come back late, state updates in the background, and the bug may already have shifted by the time you look at it.

When everything looks correct

A lot of confusing bugs start here. The code looks fine in the debugger, but the app still behaves badly. This usually means the problem is not in the line you are looking at. It may be in what happened before that line, or after it, or somewhere completely different.

This is very common in frontend work. A component may show the right props, but the state is already stale. A hook may run with old data. A callback may still be using an earlier value. In backend code, a request may arrive at the right place but with data that was changed by another process. In both cases, the debugger is honest, but only for that second.

Why state causes trouble

State is where many bugs hide. It changes quietly, and sometimes it changes in more than one place. A local variable may look perfect, but the real issue is the state that was copied earlier and never updated. A UI may look correct on screen, while the internal data is out of sync.

The issue is usually the flow around it. That's also the reason why bugs in modern apps can feel harder than they should. The code may be doing exactly what you wrote, but not what you thought it would do.

Logs can confuse you

Logs help a lot, but they can also mislead you if you trust them too much. A log only shows what you decided to print. If the important branch never ran, the log will not tell you that. If a promise resolved later, you may miss the real order of events. If an error happened before your log line, the message can give you the wrong idea.

That is why logs work best when they show movement. I usually find them most useful when they capture input, output, and any point where the program changes direction. A single log line not always tells the full story.

Hot reload and cache make it worse

Sometimes the bug is not even in the code you think you are running. Hot reload can keep old state alive. Browser cache can hold on to old files. Service workers can serve stale assets. A local build can look updated while the browser is still running something older.

These bugs are annoying because they make you doubt yourself. You change the code, refresh the page, and still see the old behavior. It feels like the debugger or the code is broken, when the real issue is often the environment. That is why clearing cache, restarting the dev server, or opening a clean session fixes more problems than people expect.

Local and production are different

A bug on your machine is not always the same bug users see in production. Something that behaves fine locally can fail under real load or with real user actions.

Local debugging is only part of the job. It helps you narrow things down, but it does not always show the whole picture. Production needs its own signals like logs, error tracking, metrics, traces, and good reporting.

What helps

When a bug refuses to show itself, I think it helps to stop looking only at the line in front of you.

A few simple habits make this easier:

Watch the full flow rather than just one line.
Check values before and after async work.
Clear cache when behavior looks stale.
Restart the app when hot reload feels suspicious.
Add temporary logs around the change in state.

These small steps reveal what the debugger is missing.

Final thoughts

The debugger is useful, but it is not the whole truth. It shows you one moment, and sometimes that moment is not the one that matters. Real debugging is more about understanding flow, state, timing, and environment. Once you start thinking that way, hard bugs become less mysterious.

For more such developer content, visit:
https://vickybytes.com

How Beginner Developers Can Find Great Project Ideas

Shrestha Pandey — Mon, 06 Jul 2026 18:12:33 +0000

Every beginner developer hits the same issue at some point. You learn a few basics, finish a tutorial, and then you have no idea what to build next. That gap can feel bigger than learning the code itself, because now the question is not “How do I write this?” but “What should I build at all?”

This article is for that moment. I want to make it simple, practical, and useful, because project ideas do not need to be too advanced to be valuable. A good project is one that teaches you something, keeps you going, and gives you enough confidence to build the next one.

Why project ideas are important

There’s a common thing that I have noticed in most of the beginners, that is, watching too many tutorials. Tutorials are helpful, but actual learning starts when you try to build something on your own. That is when you start facing real decisions, small bugs, unclear logic, and the feeling of connecting different parts into one working product.

That is one of the reasons why project ideas matter so much. The right idea gives you direction, but it also gives you energy. When the project feels too huge, you get stuck. When it feels too small or boring, you stop caring. The sweet spot is a project that feels possible and still a little exciting.

This matters even more today. Tools like ChatGPT or Copilot can help you write code faster, but that doesn't solve the real problem beginners have. Writing the code was never the hard part for long but knowing what to build is.

Start with problems you already know

The easiest project ideas often come from your own life. Think about small things you do every day that feel annoying, repetitive, or messy. A simple to-do list, habit tracker, note saver, expense log, study planner, or meal planner can all become strong beginner projects if you build them well.

This works because the problem is already familiar to you. You do not have to invent a fake use case or force a complicated feature list. You already know what the app should do, what feels useful, and what would make it easier to use.

Borrow ideas from tutorials, then make them yours

Tutorial projects are not bad. In fact, they are one of the best ways to learn. But you need to avoid copying them word for word and calling it done. If you followed a weather app tutorial, try changing the design, adding saved cities, showing alerts, or making the app work for your own city list.

This small change matters a lot. It turns a passive learning exercise into a valuable project. You still get the guidance, but you also start making choices on your own, and that is where confidence starts growing.

Look at everyday tools

Another easy way to find ideas is to look at tools you already use. Think about apps for tasks, reminders, shopping lists, expense tracking, journaling, or learning. These tools are popular because they solve simple problems clearly, and beginner developers can build smaller versions of them without needing a huge team.

You do not need to recreate the full product. A clean, focused version is enough. A mini version of a notes app or a simple budget tracker can teach you a lot more than a random overcomplicated idea that you never finish.

Turn one feature into one project

Beginners often make the mistake of thinking a project needs many features to be impressive. It does not. A tiny, focused project is often better because it is easier to finish and easier to understand. For example, one feature can become one project. A form that saves data. A search bar that filters results. A login page with validation. A dashboard that shows one useful metric. When you build around one clear action, the project feels manageable and still useful.

Try something small with AI in it

You don't need to build a big AI product. A small one still teaches you a lot, like how to call an API, handle a response, and manage what's happening on screen. A few simple ideas:

A tool that shortens long articles or text
Something that turns your notes into flashcards
A small tool that answers questions from a PDF you upload
A journal app that gives you a short reply based on what you wrote

A simple, working version of any of these makes a solid beginner project.

Use communities for inspiration

If your own ideas feel stuck, look at what other beginners are building. GitHub, Dev.to, Reddit, Discord communities, hackathon submissions, project labs and open-source repositories can all give you fresh direction. This way you start to notice patterns, problems, and styles of projects that keep appearing. You will often find that many useful ideas are small variations of the same core concept. Most great beginner projects are not original inventions, but they are thoughtful versions of common ideas with a personal twist.

Think in “versions”

A lot of beginners wait for the perfect idea, that usually delays everything. A better way to think is in versions. Version one can be simple and ugly, as long as it works. Version two can improve the design, and version three can add one or two stronger features. This way of thinking helps you start faster. It also keeps you from quitting because the idea feels too ambitious. You are not building the final version of a startup. You are building something that helps you learn, ship, and improve.

Make the project useful to someone

A project becomes more meaningful when it helps a real person, even in a small way. That person can be you, a friend, a student, or a small community. When you know who it is for, the idea becomes easier to shape.

For example, a revision planner for students, a simple content calendar for creators, or a shared checklist for a small team already has a clear purpose. The moment you know the user, you start building something that makes sense.

A simple way to choose

If you still do not know what to build, use this simple test.

Ask yourself:

Can I explain this idea in one sentence?
Can I build a first version in a reasonable amount of time?
Will I learn something new from it?
Do I care enough to finish it?

If the answer is yes to most of these, you probably have a good project idea.

What to avoid

Try not to start with ideas that are too broad. “Make a social media app” sounds exciting, but it often turns into confusion fast. Huge projects can be motivating at first, then frustrating once the scope starts growing. Also avoid choosing an idea just because it sounds impressive. The best beginner projects are often the ones that teach you core skills clearly. A simple app that you actually finish is far more valuable than a complex one that stays half-done.

Where Creator Labs fits in

If you are someone who learns better with guidance, structured challenge spaces can help a lot. That is one reason places like Creator Labs by VickyBytes can be useful for beginners who want direction, ideas, and a nudge to actually build. It is easier to stay consistent when you have a place that keeps you thinking in terms of projects, not just tutorials.

I like that kind of setup because it helps beginners move from “I know the basics” to “I can build something real.” That transition is where most people get stuck, and that is where the right support can make a difference.

Final thought

Finding a great project idea is all about noticing small problems, starting with something simple, and building in a way that keeps you moving. The best ideas are usually the ones you can explain clearly, start quickly, and finish without losing interest.

If you are a beginner, give yourself permission to build small. A finished small project teaches more than an unfinished big one, and every strong developer starts by making that first real thing

The Best AI Tools for Developers in 2026

Shrestha Pandey — Sat, 04 Jul 2026 12:46:52 +0000

AI tools for developers are everywhere right now. Some are genuinely useful, some are overhyped, and some only fit a very specific kind of workflow. AI has moved from basic autocomplete into something that can help with debugging, refactoring, code review, app scaffolding, and parts of deployment too.

This post looks at the tools that keep coming up in real developer conversations and the kinds of tasks they actually help with. The goal is to know which tool makes your day-to-day work smoother, faster, and less annoying.

Why this topic

A few years ago, most AI coding tools were mostly about completing lines of code. In 2026, the conversation is much broader. Developers are using AI for explanation, planning, code generation, debugging, review, and workflow cleanup.

That matters because in software development, a lot of the job is reading unfamiliar code, making safe changes, reviewing pull requests, and moving through repetitive work without losing focus. The best AI tools are the ones that help with those parts.

What counts as a useful AI dev tool

For this article, I’m focusing on tools that help with real development work. That includes code completion, editing, reasoning through bugs, generating app scaffolds, reviewing code, and speeding up routine tasks. I’m also keeping the definition practical. A product can call itself “AI for developers”, but that does not automatically make it useful. The tools that matter are the ones that save time without getting in the way of quality.

The editor-first options

Cursor is one of the most talked-about AI-first coding environments right now. It gives you an AI-driven editor experience rather than just a plugin layered on top of an existing setup. That makes it appealing if you want the assistant to feel closely connected to the code you’re working on.

GitHub Copilot still makes a lot of sense for developers who want AI help without changing their habits too much. Its strength is that it fits naturally into workflows people already use every day. For many developers, that familiarity matters more than having the newest interface.

The reasoning-heavy helpers

Claude Code comes up often in conversations about harder coding tasks. People tend to reach for it when they want help reading large codebases, untangling bugs, or working through bigger refactors. That kind of tool is useful because a lot of developer time goes into figuring out what a system is doing before writing the fix. When the problem is messy, a tool that helps you think more clearly can be worth a lot.

The terminal-friendly choices

Aider stands out because it fits well into a Git-based workflow. It works for developers who like staying in the terminal and want AI edits tied directly to the repository and change history.

This category matters because not every developer wants a full AI-first IDE. Some people prefer smaller tools that feel close to the command line and less disruptive to the way they already work. For them, a terminal-friendly assistant can feel much more natural.

The newer all-round contenders

Windsurf is another name that keeps showing up in 2026 AI tool conversations. It sits in the same broad category as other AI-first coding environments, so the real decision usually comes down to workflow fit, pricing, and how the tool behaves in practice.

The bigger point here is that the market is no longer about one dominant product. It’s about which tool removes the most friction from your own workflow. That is why people keep comparing these tools by use case rather than treating one of them as the universal answer.

What these tools do well

The most useful AI tools are the ones that remove friction from repetitive parts of development. That usually means generating a first draft faster, explaining unfamiliar code, helping with small edits, accelerating debugging, or handling tedious transformations. That kind of help can make a real difference during a busy week. It gives you more room to focus on the parts that need judgment, like architecture, testing, and code quality.

What to be careful about

AI can make people feel productive very quickly. That can be helpful, and it can also be risky if you move faster than your understanding. Generated code still needs review. Suggestions still need testing. If a tool helps you ship faster without helping you understand the changes, that speed can become a problem later when the code needs maintenance or collaboration.

My honest take

If you are choosing one tool to start with, pick the one that fits how you already work. If you want an AI-first editor, Cursor is a strong place to look. If you want a familiar workflow with low friction, Copilot still makes sense. If you want help thinking through harder code, Claude Code is worth exploring. If you like terminal-based work, Aider is a practical option.

I would not frame this as a one-tool-fits-all situation. Different tools solve different problems, and the best one is the one that helps you ship better work with less friction. The best AI tools for developers in 2026 are not always the loudest ones, they are the ones that make development smoother, clearer, and less repetitive without getting in the way of quality.

How to Deploy Your ML Model to AWS (Step-by-Step Guide)

Shrestha Pandey — Mon, 22 Jun 2026 07:21:40 +0000

I've trained more ML models than I've deployed. There's something comforting about the local loop—model.fit(), model.evaluate(), hitting 94% accuracy, then staring at the screen wondering, "Okay, how do I make this actually useful?"

If you're stuck there right now, this guide will help.

Note: I wrote this based on AWS documentation and standard SageMaker patterns. If you try it, drop a comment about what worked (or broke).

What You Need Before Starting

AWS account with SageMaker enabled
A trained model saved as model.pkl (or .joblib)
requirements.txt with your dependencies
Python 3.8+ installed
AWS CLI configured (aws configure)

Step 1: Save Your Model

import joblib
joblib.dump(model, 'model.pkl')

Create a requirements.txt file:

sklearn==1.2.0
pandas==1.5.0
numpy==1.23.0`

Keep both files in the same folder.

Step 2: Upload to S3

import boto3

s3 = boto3.client('s3')

bucket_name = 'my-unique-ml-bucket-12345'  # Make this unique
s3.create_bucket(Bucket=bucket_name, CreateBucketConfiguration={
    'LocationConstraint': 'us-east-1'
})

s3.upload_file('model.pkl', bucket_name, 'models/model.pkl')
s3.upload_file('requirements.txt', bucket_name, 'models/requirements.txt')

model_s3_path = f's3://{bucket_name}/models/model.pkl'

Step 3: Write Your Inference Script

Save this as inference.py:

import json
import joblib
import numpy as np
import os

model = None

def model_fn(model_dir):
    return joblib.load(os.path.join(model_dir, 'model.pkl'))

def input_fn(input_data, content_type):
    if content_type == 'application/json':
        data = json.loads(input_data)
        return np.array(data['features'])
    raise ValueError(f"Unsupported content type: {content_type}")

def predict_fn(input_data, model):
    return model.predict(input_data)

def output_fn(prediction, content_type):
    return json.dumps({'predictions': prediction.tolist()})

These four functions are what SageMaker calls when someone hits your endpoint.

Step 4: Deploy Using Python SDK

Run this in a Python script:

from sagemaker.sklearn.model import SKLearnModel
from sagemaker import get_execution_role

sklearn_model = SKLearnModel(
    model_data=model_s3_path,
    role=get_execution_role(),
    instance_type='ml.m5.large',
    entry_point='inference.py',
    py_version='py3'
)

sklearn_model.deploy(
    initial_instance_count=1,
    instance_type='ml.m5.large',
    endpoint_name='my-model-endpoint'
)

This takes 5–10 minutes. You'll see Creating → In Service.

Step 5: Test Your Endpoint

import boto3
import json

runtime = boto3.client('sagemaker-runtime')

response = runtime.invoke_endpoint(
    EndpointName='my-model-endpoint',
    ContentType='application/json',
    Body=json.dumps({'features': [[5.1, 3.5, 1.4, 0.2]]})
)

result = json.loads(response['Body'].read().decode())
print(result)

If you see {'predictions': [...]}, it worked.

Step 6: Clean Up

Endpoints cost money even when idle:

aws sagemaker delete-endpoint --endpoint-name my-model-endpoint
aws sagemaker delete-endpoint-config --endpoint-config-name my-model-endpoint

Common Errors (And Fixes)

Error	Fix
`NoCredentialsError`	Run `aws configure` again
`InvalidRoleException`	IAM role needs S3 + SageMaker permissions
`ModelError`	Check `inference.py` for missing imports
Endpoint stuck on `Creating`	Wait 5–10 more minutes

Your IAM role needs:

s3:GetObject, s3:PutObject
sagemaker:CreateModel, sagemaker:CreateEndpoint

Cost Breakdown

Resource	Cost
`ml.m5.large`	~$0.20/hour (~$6/month if 24/7)
S3 storage	~$0.02/GB/month

Delete when not using. I've seen $50 surprises from idle endpoints.

Verify This Before You Trust It

If you're following this, check:

AWS SDK version — Run pip show boto3 sagemaker
IAM role permissions — Biggest blocker is usually missing permissions
Region mismatch — S3 bucket region must match SageMaker region
Inference.py imports — Make sure os, joblib, numpy are installed

If something breaks, comment below with the error. I'll update this guide.

Final Thoughts

Deploying ML feels intimidating until you do it once. SageMaker handles most of the complexity. You just upload your model to S3, point SageMaker at it, and deploy.

I've trained models that sat on my laptop for months because I didn't know how to deploy them. Now I tell people: "Just run this script, it's not that hard."

If you're building something with this, drop a comment. I love seeing what people deploy.

70B AI Model Runs on 8GB Laptop

Shrestha Pandey — Tue, 16 Jun 2026 18:29:25 +0000

You needed a $100,000 server to run huge AI models. Now you can do it on a regular laptop. One developer figured out how, and it changes everything for students, developers, and small companies who want to use AI without breaking the bank.

A few years ago, running LLaMA 70B required serious hardware, multiple GPUs, 80GB RAM per GPU., a server rack costing more than a car, due to which most people couldn't touch it. You either worked at a big tech company with a data budget, or you couldn't run these models at all.

In 2026, you can run the same model on a laptop with 8GB RAM. The laptop you bought three years ago. The one on your desk right now and it works.

What Happened

A developer uploaded something to GitHub called AirLLM. The README said: "Run 70B models on 8GB RAM. No GPU required." That's the whole pitch.

Developers downloaded it. They tested it on old laptops and budget computers. Even on machines that should not work, and it worked.

How It Works

A 70B model takes about 140GB of RAM normally. Even compressed to 4-bit, you still need 35GB. Mostly, laptops don't have that.

AirLLM gets it down to 8GB. It loads the model differently. Instead of putting everything in RAM at once, it loads parts. When you ask it something, it loads the layers it needs, answers, then swaps them out for the next layers.

Like reading a book page by page instead of holding all 1,000 pages at once. AirLLM does this with the model. The model is still 70 billion parameters. It's still smart but it never needs all that memory at the same time.

The technique uses memory mapping and layer swapping. Both are old ideas but putting them together in one tool is what made it work.

Is It Fast?

No. Running a 70B model on 8GB RAM from a laptop is slower than running it on a server. You're trading speed for getting it to work at all.

On a 2021 MacBook with 8GB RAM, AirLLM generates about 3-5 tokens per second. That's readable. You can chat with it and ask questions, which was not instant, but still usable.

On a faster laptop with 16GB RAM? Maybe 8-12 tokens per second. Close to real-time.
On a server with a GPU? 50-100 tokens per second. That's the speed people expect.

So AirLLM is slower, but it works on computers that are not expected to work.

Who Can Use This?

Students don't need a $10,000 computer to learn AI. They can run huge models on the laptop their parents gave them, which removes the biggest barrier to learning.

Developers can test AI locally without sending data to the cloud. Their code stays on their machine and their questions stay private.

Small companies don't need to rent GPU servers from AWS or Google Cloud. They can run models on regular computers. That saves thousands of dollars every month.

What Models Work?

AirLLM supports LLaMA 2 70B, Mistral 7B, Gemma 2 27B, and Falcon 180B if you have more RAM.

The 70B models are the sweet spot. They are big enough to be smart and small enough to fit on a laptop when compressed.

You can also run smaller models faster. A 7B model on AirLLM runs at 20-30 tokens per second on a regular laptop, which is instant.

The Tradeoffs

Speed is slower: A 70B model on a server is 10-20x faster. If you need speed for production, AirLLM is not for you.

Quality drops a bit: The model is compressed to 4-bit, which means less precision. But it still answers well and makes sense.

The model takes about 35GB of disk space. So your laptop gets hot and the fan gets loud, maybe after 10 minutes.

How to Run It

You need Python.

bashpip install airllm

Download the model from Hugging Face:

pythonfrom airllm import AirLLM

model = AirLLM("meta-llama/Llama-2-70b-hf")
response = model.generate("What is quantum computing?")
print(response)

Final Thoughts

AI is no longer controlled by companies with money. You don't need to send questions to a cloud server, pay for API calls, or wait for a company to give you access. You can run the model yourself on your computer.

It's not perfect and fast, but it works. And it works on a laptop with 8GB RAM.

A few years ago, running a 70B AI model was fantasy. You needed a data center. But now, you need a laptop. It's a power shift.

AI is no longer just for the rich, it's for anyone with a computer.

Resources

AirLLM GitHub — The main tool
LLaMA 2 70B on Hugging Face — Download the model

Note: Edited with AI Assistance

AI Created Its First Real Cyber Attack And It Bypassed 2FA

Shrestha Pandey — Thu, 11 Jun 2026 21:46:05 +0000

For the first time, AI has been used to exploit a software vulnerability. Google discovered it in May 2026, and the consequences could be serious.

The Moment Everything Changed

In May 2026, Google’s Threat Intelligence Group identified something that security researchers had been warning about for years, and it came sooner than expected.

Hackers used an AI model to create a working zero-day exploit, a cyber attack that targets a vulnerability no one knows about yet. And it wasn’t a simple attack. It bypassed two-factor authentication (2FA), the security layer that millions of people trust every single day.

This is the first case of AI weaponizing a vulnerability for real-world attacks. Before this, zero-days required elite hackers and months of research. But now, AI can find them in hours.

Let’s breakdown what happened and why it’s so terrifying.

What Got Attacked?

The target of attack was an open-source web-based system administration tool. Google didn’t disclose the name, but it’s a popular system that IT companies used to manage servers, websites and computers.

The exploit let attackers log in without entering the second authentication code, even when 2FA was turned on. You could enter the password and the system would log you in directly, skipping the phone code setup completely.

The vulnerability was not just some coding mistake like memory error, it was a logic flaw.

The developers hardcoded something like:

if user_is_admin:
skip_2fa = True

The traditional security scanners missed it, but AI found it.

How the Attack Worked?

The AI used by hackers, wrote some Python script.

The script still needed valid credentials to work, so knowing the correct password was required. But as soon as it had these credentials, it was able to bypass 2FA entirely. There was no phone code or verification required, and it went straight into the account.

The major plan was mass exploitation. The cybercrime group wanted to use this on thousands of users of the tool at once. There goal was going after everyone using the software, not just one company.

Google worked with the vendor to fix the vulnerability so the mass exploitation didn’t happen. But the exploit was real and AI created it.

The AI Tells: How We Know It Was AI

This was not just an assumption, the code had clear AI fingerprints.

Overly Explanatory Comments: The script had comments that explained what every function did, like a teacher walking through code. Human hackers don't write comments like that, but AI does.
A Hallucinated CVSS Score: The code had a CVSS score, that is, a security vulnerability rating, but the score didn't really exist, AI made it up.This was a hallucination, a common AI mistake.
Textbook Python Format: The code was perfectly clean without any hacker shortcuts or any optimizations. It was like a textbook Python from AI training data.
A Junk _C Color Class: The script used a basic ANSI color class named _C. It's a common pattern in AI-generated code. Google found this exact pattern in multiple AI scripts.

A human hacker wouldn't include these points. They're too neat, too educational, too obvious, which indicates AI does this.

Why AI Found This Flaw

Zero-day vulnerabilities require elite security talent. It actually needs someone who can read code, understand intent, and spot contradictions, which is hard.

Modern large language models (LLMs) have something called context reasoning. They can:

Read through thousands of lines of code
Understand what the developer was trying to do
Find contradictions between intent and implementation
Surface logic errors that look correct but are broken

The zero-day was a high-level logic flaw. Security scanners don’t catch these. They look for memory errors, syntax mistakes, known vulnerability patterns, but they don’t understand developer intent.

Google said frontier LLMs (the biggest AI models) are getting better at this. They can spot logic errors the way a senior security engineer would. But they do it faster, and they don’t get tired.

Why This Changes Everything

The scary part is, this will happen more.

Zero-Days are now scalable: Before AI, finding a zero-day was skilled work but now, AI can scan code, find logic flaws, and write exploits in hours.
2FA is not 100% safe: Two-factor authentication is the gold standard for security. It’s what you tell your employees to use. It’s what banking apps require to keep accounts safe. This exploit bypassed it.
AI can find flaws humans miss: Traditional security tools look for patterns, check for known vulnerabilities, but they don’t understand intent. AI understands intent, reads code like a human would and finds contradictions, that are the most dangerous vulnerabilities.

What Developers Should Do Right Now

You can’t stop AI from finding vulnerabilities, but you can make yourself a tougher target.

Update Your Packages Faster: When a vulnerability is announced, patch it as soon as you can. Attackers are moving faster with AI, so waiting weeks to update is a risk. If there’s a fix, apply it quickly.
Audit Your Dependencies: Check what libraries and tools you're using. Are they popular? Do they have security teams? Are they open-source? Audit your entire dependency tree. Each one is a potential attack vector.
Don't Trust AI Code 100%: If you use AI to write code, always review it. AI can get things wrong, add insecure code, or suggest solutions that don’t really work.
Get Ready for More AI-Powered Attacks: AI-driven attacks aren’t going away. Set up monitoring, watch for unusual activity, rotate passwords and keys regularly, and have a plan for handling security incidents.

Final thoughts

The AI-created zero-day is a turning point. It shows that AI is no longer just a future threat, it's already being used in real attacks.

2FA is still a strong layer of security, but it’s not perfect. Logic flaws are still dangerous, and now AI can help find them faster. Zero-days are still uncommon, but creating them is becoming easier.

This is just the beginning.

The next thing could be much bigger.

I Fine-Tuned Llama 3.2 on My Own Writing Style Using LoRA, Unsloth, and a Free Colab GPU

Shrestha Pandey — Sun, 07 Jun 2026 14:38:38 +0000

For a long time, fine-tuning language models felt like something that multiple people talked about, but very few actually tried themselves.

Whenever I saw posts about fine-tuning, I saw things like massive datasets, GPU setups, and much more, which made me realise it’s out of reach. But it got added to my list of things to explore.

Recently, while browsing Creator Labs on VickyBytes, I came across one of those labs which sounded simple yet practical to someone like me, who wants to explore. It was: taking a small language model and fine-tune it on your own writing style. The main goal here was, Could a model learn to write more like me?

As someone who spends a lot of time creating technical content, that question caught my attention.

I assumed fine-tuning still needed expensive hardware, large datasets, and a significant amount of machine learning knowledge. Instead, I tried to lower the barrier and discovered tools like using Google Colab notebook, LoRA, and a small dataset built from my own content.

This article documents the entire process from start to finish, including environment setup, dataset preparation, LoRA fine-tuning, evaluation, GGUF conversion, and the lessons I learned along the way.

What Does "Training on Your Writing Style" Actually Mean?

A language model doesn’t understand who you are. It learns the statistical patterns present in your writing.

For example:

Do you prefer short or long paragraphs?
Do you use analogies?
Do you use emojis in your writing?
Do you end posts with questions?
Do you write formally or conversationally?

When enough examples are provided, the model begins reproducing those patterns.

Thus, fine-tuning on writing style is less about teaching a model who you are and more about teaching it how you tend to communicate.

Architecture Overview

Choosing a Model

The lab suggested working with models between 1B and 7B parameters. Initially, I considered using one of the newer Qwen models. However, after exploring the available Unsloth notebooks, I decided to use:

Llama 3.2 3B Instruct

Three reasons for this decision were:

First, the model was small enough to fine-tune comfortably on free Colab resources. Second, Unsloth provides a mature training notebook for Llama models. Third, the resulting model can easily be exported to GGUF and run locally through Ollama.

At this point, I wanted a model that could actually learn from a relatively small dataset and allow me to complete the entire worlflow on consumer-grade hardware.

Setting Up the Environment

I wanted the entire project to work on free resources. So instead of renting a GPU or using paid cloud infrastructure, I used Google Colab because it provides access to a free NVIDIA T4 GPU, which is sufficient for LoRA fine-tuning small language models such as Llama 3.2 3B.

The first step was GPU acceleration.

From the Colab runtime settings, I selected a GPU runtime as T4 GPU.

Once the runtime was ready, I opened the official Unsloth notebook for Llama 3.2 and executed the setup cells.

Unsloth handles much of the optimization automatically, which means there is very little configuration required from the user.

Building and Preparing the Dataset

This was the most important step in the entire project.

Most of us think focus on discussing models instead of discussing more about the data. I experienced that building the dataset was more challenging as the result depends on the data we provide.

Since the goal was to teach the model my writing style, I built the dataset using content I had already written over time, including LinkedIn posts, Instagram captions, technical explanations, and educational content. I focused on examples that showed how I naturally write and explain technical concepts.

One challenge I encountered was preparing the data in the format expected by the training pipeline. So, I converted each example into an instruction-response pair.

Example:

{
  "instruction":"Write a LinkedIn post about Kubernetes",
  "response":"Kubernetes is one of those technologies..."
}

The notebook expected a JSONL dataset, where each example is stored as a separate JSON object. Initially, I spent some time on dataset loading errors before realizing the issue was with the structure of the data. To simplify, I stored the examples as a Python string inside the notebook and generated the dataset.jsonl file before loading it.

Once the dataset was formatted correctly, it loaded successfully and became the foundation for the rest of the fine-tuning process. It looked simple but it was one of the most important parts of the entire project because the model can only learn the patterns that exist in the data it receives.

Loading the Dataset

After correcting the JSONL structure, loading the dataset became simple.

from datasets import load_dataset

dataset = load_dataset(
"json",
data_files="dataset.jsonl",
split="train"
)

To verify everything loaded correctly:

print("Rows:",len(dataset))

Preparing the Dataset for Llama 3.2

The raw dataset still wasn’t ready for training because Llama expeects conversational data rather than instruction-response pairs.

To solve this, I used Unsloth’s chat template utilities.

from unsloth.chat_templates import get_chat_template

tokenizer = get_chat_template(

tokenizer,

chat_template="llama-3.1"

)

This converts the dataset into the same format used by Llama during instruction tuning.

A single training example now looks something like this:

<|start_header_id|>user
Write a LinkedIn post about Docker

<|start_header_id|>assistant
Docker revolutionized...

At this stage, the model finally has data in a format it understands.

Fine-Tuning with Unsloth

Once the dataset was completely ready, the training process became surprisingly easy.

Using Unsloth’s SFTrainer, I configured LoRA training and launched the run.

trainer.train()

During training, the model repeatedly sees examples from the dataset and adjusts the LoRA adapter weights to better reproduce the expected responses. The original Llama weights remain frozen throughout the process.

Did the Model Actually Learn My Writing Style?

Now, after training, the main question was whether the model learned anything useful. To test this, I intentionally used prompts that were not included in the dataset.

Examples included:

Prompt:
Explain LLMs in short

Generated Output:
Most AI today runs on a small change. Instead of building LLM itself, you give an AI model large amounts of text data and tell it to only remember things it decides on its own. This creates a system where the AI learns by responding to other people’s queries, and where it has to think for itself in order to provide an accurate answer. That’s a major pattern behind the AI today. Instead of fine-tuning a model that thinks like a dictionary and a research paper in one, you fine-tune a model that thinks like a person. And instead of giving it years of training data, you give it hundreds of thousands of your own pages that it will decide what to keep in memory on its own. That is the system most AI use today, and it has worked well for a lot of things.

The output were not identical to my writing. That would actually be a bad sign because it would suggest memorization. The generated posts were more conversational, and more focused on helping readers understand concepts rather than simply describing them.

That was the behavior I expected to achieve.

Avoiding Overfitting

One challenge with small datasets is overfitting.

With only twenty examples, there is always a risk that the model memorizes responses instead of learning general writing patterns.

To reduce that risk, I intentionally included multiple content formats and multiple technical topics. Using diverse topics helped push the model toward learning style patterns instead of topic-specific answers.

Exporting the Model to GGUF

After training completed, I expected to see a complete model. But LoRA only trains adapters. Those adapters must be merged with the original model before deployment.

The workflow looks like this:

Using Unsloth’s export utilities, I generated a GGUF version of the model using Q4_K_M quantization. This format is widely used by tools such as Ollama and llama.cpp.

Running the Model Locally with Ollama

One of the coolest part was realizing that the model no longer needed Colab. Once exported as GGUF, it could run locally.

Using Ollama, the fine-tuned model can be loaded directly from a laptop without relying on external APIs.

This means the writing-style model becomes self-hosted. The same personalized behavior learned during fine-tuning can now be accessed locally whenever needed.

Ethical Considerations

Since this project involved training on personal content, it’s worth discussing about the privacy. I only used the content that I personally wrote and was comfortable using for experimentation.

I avoided using private messages, confidential conversations, or any data that could create privacy concerns.

The ability to train models on personal data is powerful, but consent and security should always be considered before building such AI systems.

Lessons Learned

While working on this project, I learnt a few things.

The most challenging parts were:

Building a useful dataset
Correctly formatting JSONL files
Understanding chat templates
Understanding LoRA adapters
Evaluating whether the model genuinely learned anything

The actual training process ended up being the easiest step. Modern tools such as Unsloth have simplified fine-tuning workflows. So the actual bottleneck is data quality, not just the hardware.

Final Thoughts

Before starting this project, fine-tuning felt like something made only for machine learning engineers.

After completing it, I think every developer should try it once.

Something that surprised me was how strongly the dataset influenced the final results. Even with a small collection of examples, the model began reproducing many of the patterns that consistently appear in my writing.

And after spending several days building, debugging, training, evaluating, and exporting the model, I’m convinced that the quality of the examples matters a lot.

Would I use this model for real content creation? Probably not yet. The dataset is still too small, and the outputs occasionally differ from my writing style.

However, the experiment successfully demonstrated that modern fine-tuning tools have lowered the barrier significantly. Something that once felt like a machine learning research project can now be completed on a free Colab GPU over a week.

Resources

Fine-Tuning Framework: Unsloth
Model Notebooks: Unsloth Notebook
Running Models Locally: Ollama
GitHub Repository: Fine-tuning-LLM-to-write-in-your-own-style
Lab Inspiration: VickyBytes Creator Labs