DEV Community: Shrestha Pandey

The Truth Behind OpenAI's 10,000-Agent Math Claim

Shrestha Pandey — Wed, 09 Sep 2026 19:55:10 +0000

On September 8, 2026, OpenAI published a paper claiming that an internal, unreleased AI system had made progress on one of the seven Millennium Prize Problems: the Navier–Stokes existence and smoothness problem. The announcement got a lot of attention fast, partly because of the result itself, and partly because of how it was produced — a coordinated swarm of roughly 10,000 AI agents working in parallel.

As developers, we've all seen "AI solves impossible problem" headlines before, and most of them fall apart under scrutiny. This one is more interesting than most, but it also comes with real caveats that are worth understanding before you repeat the claim anywhere. Here's a breakdown of what was actually done, how the multi-agent workflow worked, and why the story isn't as clean as the headline suggests.

The problem

The Navier–Stokes equations describe how fluids move — they're used in weather forecasting, aircraft design, and blood flow modeling, among other things. They work great in practice. What's never been settled mathematically is whether, under the right conditions, a smooth three-dimensional fluid flow could spontaneously "blow up" — meaning some property like velocity shoots to infinity in a finite amount of time, breaking the model.

Proving whether that kind of breakdown, called a singularity, can or can't happen has been an open question since the 1930s. In 2000, the Clay Mathematics Institute put a $1 million prize on it, and it's remained one of the hardest open problems in math ever since.

OpenAI says its system produced a proof that a singularity can, in fact, form in finite time from a smooth, physically reasonable starting state — and that this proof has been formalized and checked in Lean, a proof-verification language that mathematicians use to catch logical errors that are easy to miss by eye.

How the multi-agent workflow worked

This is the part that's genuinely new, at least in scale. According to OpenAI's own writeup, the process looked roughly like this:

Starting in late August 2026, OpenAI trained a new internal model that outperformed its already-released flagship model on math benchmarks.
After hearing rumors that a rival lab might be close to solving a different Millennium problem, OpenAI decided to point this model at all of the unsolved Millennium Prize problems at once, plus a handful of other hard open problems.
Rather than running one long conversation with one model, they spun up large groups of coordinating agents. Each agent group could talk to other agents within its group, and different groups were given different framings of the same problem — some aimed at proving a statement true, others aimed at disproving it.
The group that eventually cracked the Navier–Stokes case grew to around 10,000 agents running at the same time.
Every so often, researchers used a coding-focused model to pull out the most promising partial results from different groups and feed them back in as new prompts, essentially cross-pollinating ideas between otherwise separate lines of reasoning.
Along the way, a smaller group of under 100 agents also worked out a related, slightly easier problem (a version of the same blow-up question for the Euler equations, which is what you get when you remove viscosity from Navier–Stokes). That intermediate result apparently helped point the larger effort in the right direction.
The full effort took about 88 hours of agent work, followed by another 17 hours to formalize and verify the proof in Lean.
Across the whole project, the agents exchanged close to 5 million messages and generated somewhere in the neighborhood of 300 billion output tokens.

So the "workflow" is closer to a massive, structured search process: many parallel attempts, deliberate diversity in approach, periodic synthesis of the best ideas, and a hard formal-verification step at the end to catch mistakes.

Why you shouldn't treat this as a settled result yet

A few things are worth flagging clearly:

It hasn't been independently certified. This is OpenAI's own internal evaluation, checked by their own Lean formalization. The Clay Mathematics Institute has not verified it, and OpenAI itself has said it isn't claiming the prize for this result. Outside mathematicians need time to review it properly, and that process is still ongoing.

There's an unresolved priority dispute. Around the same time, a mathematician at NYU and a researcher at a rival AI lab had been working for roughly a year on a closely related problem, using a mix of AI tools from both labs, and had reportedly made a breakthrough of their own just days before OpenAI's announcement.

OpenAI acknowledges it only started this specific push after hearing rumors about that other team's progress. The two results turned out to address related but not identical versions of the underlying question. Public statements from the NYU mathematician have raised pointed concerns about how OpenAI handled credit and communication during this period; OpenAI has disputed parts of that account. That dispute is still playing out publicly and isn't fully resolved.

Respected mathematicians are uneasy about the pattern. Some senior figures in the field have pointed out a broader worry: if AI labs increasingly treat famous open problems as marketing opportunities, and only publish final answers without the failed attempts and reasoning that usually teach the field something, it could quietly damage how mathematical progress actually happens — even when the individual results are correct.

What this means for practitioners

Setting aside the drama, the workflow pattern here is genuinely relevant to anyone building agentic systems:

Diversity over depth, at least initially. Running many independently-framed attempts in parallel found a promising lead that a single deep attempt might have missed.
Cross-pollination beats isolation. The step where useful partial results were pulled out of one group and fed into others was described as a turning point, not an afterthought.
Formal verification matters when correctness is non-negotiable. The Lean formalization step is doing real work here — it's the difference between "a model that sounds convincing" and "a proof that's been mechanically checked line by line."
Scale isn't free, and it isn't magic. Getting to this result reportedly took vastly more compute than OpenAI has used for past math results — and it still produced a result that overlaps with, rather than clearly surpasses, work already underway by human mathematicians assisted by AI tools.

The takeaway

OpenAI's claim is real in the sense that a formally-verified proof exists and has been published. It is not yet an independently confirmed, prize-worthy resolution of the Millennium Prize problem, and the story behind how it was produced is currently tangled up in a genuine dispute over credit and conduct with another research team. If you're citing this anywhere, the accurate framing is: "OpenAI published an unverified but Lean-checked proof, produced by a large coordinated multi-agent system, addressing a specific formulation of the Navier–Stokes singularity question".

Worth watching over the next few months as outside mathematicians actually dig into the proof.

For more such developer content, click here

GPT-6 Astra: A Developer's First Look at OpenAI's Most Capable Model Yet

Shrestha Pandey — Tue, 08 Sep 2026 07:17:00 +0000

TL;DR — GPT-6 Astra is OpenAI's newest frontier model, released September 3, 2026. It excels at end-to-end computer automation, professional document generation, and long-context coding sessions. API pricing: $10/$50 per million tokens. Best for agentic workflows, not bulk text tasks.

OpenAI just dropped GPT-6 Astra, and if you've been building with AI models over the past year, this is something different.

This model goes beyond chat. It's built to actually do work on your computer like fill forms, debug code, review security patches, even build and test small web apps—without you micromanaging every click.

I spent the last few days going through the launch docs, benchmark tables, and early developer reports to separate the marketing from what's actually useful for building real stuff. Here's what I found.

What Is GPT-6 Astra?

GPT-6 Astra is OpenAI's newest frontier model, released on September 3, 2026. It's positioned as the successor to GPT-5.6 Sol and is being called the company's "most intelligent and aligned model" to date.

Earlier models mostly generated text or code snippets. Astra is trained to operate a computer end-to-end. Like navigating websites, interacting with desktop apps, running tests, installing packages, and producing finished documents or slides that match your company templates.

The Capabilities That Matter for Developers

1. Computer Use That Doesn't Feel Like a Demo

Astra's biggest leap comes from "computer use"—the ability to take a high-level instruction and carry out the clicks, keystrokes, and navigation needed to complete it.

Examples from the launch materials:

Filling out batches of online forms (expense reports, CRM updates)
Installing and testing software while monitoring the screen for errors
Running frontend QA checks on a site you just built
Organizing calendars and drafting summaries directly in your email or docs

On OSWorld 2.0 (a real desktop task benchmark), Astra scored 72.6% at roughly 40 minutes per task, compared to GPT-5.6 Sol's 65.7% at ~75 minutes. That's 47% less time per task, which directly cuts agent cost.

2. Professional Artifacts That Don't Need Reformatting

If you've ever wasted an hour reformatting an LLM's markdown dump into a corporate slide template, this part will resonate.

Astra is trained to:

Follow existing templates for slides, docs, and spreadsheets
Match your writing and visual style
Pull only the context that matters instead of padding outputs

In OpenAI's demo, Astra built a slide deck about a fictional model using just a few template slides, keeping tone and layout consistent. For teams that produce client-facing materials regularly, that template adherence is a genuine time-saver.

3. Coding Sessions That Remember Context

Long debugging sessions or large refactors often hit the context window limit, forcing models to compress everything into a summary and lose details.

Astra introduces a new Codex feature: searchable notes across context windows. Instead of repeatedly summarizing, Codex keeps notes and leaves earlier windows searchable, so Astra can find a requirement or test result from an earlier message even if the note didn't capture it.

You can enable this experimental feature in your config.toml, and OpenAI says it'll become the default for Astra soon.

4. Cybersecurity Power (With Guardrails)

This is the most sensitive capability. Astra is the first OpenAI model to reach the Critical threshold in cybersecurity under the company's Preparedness Framework.

In internal tests without production safeguards:

100% on ExploitBench (turning known vulnerabilities into working exploits)
42.4% on ExploitGym (vs 30.3% for GPT-5.6 Sol)
88.0% on SRE-Bench (reverse-engineering binaries without source code)

Because of this, exploit-creation capabilities are gated at launch. Astra will help with secure code review and patching, but refuses to create proof-of-concept exploits until access expands via OpenAI's Daybreak program.

Expect occasional pauses where you're asked to review an action before continuing—especially on security-related tasks.

Benchmarks: The Good, the Nuanced, and the "Read the Footnotes"

Where Astra Clearly Leads

Benchmark	Astra	GPT-5.6 Sol	Claude Opus 5	Notes
OSWorld 2.0	72.6%	65.7%	70.2%	Real desktop tasks, 47% less time per task than Sol
FrontierMath Tier 4	97.6%	83.0%	73.2%	Research-grade math
ExploitBench	100%	78.5%	70%	Gated capability
Terminal-Bench 4.0	57.9%	37.3%	52.6%	Software engineering + system tasks

Where It's Not a Clean Sweep

Humanity's Last Exam (with tools): Astra scores 57.2%, behind Claude Fable 5.1's 65.0% and Opus 5's 63.6%.
ARC-AGI-3: The headline 99.9% was achieved using OpenAI's responses API harness, which changes two settings to better match real-world performance. The changes do not specifically target ARC-AGI-3.

Alignment and Safety

On OpenAI's internal computer-use safety benchmark (lower is better), Astra posts 2.4% vs 22.0% for GPT-5.6 Sol.

OpenAI's evaluations found Astra's written reasoning harder to monitor than GPT-5.6 Sol's, based on tests that explicitly asked it to evade monitoring. OpenAI attributes this to Astra's greater control over written reasoning on simpler tasks and ability to solve problems with fewer written steps. Improving monitorability remains a research priority.

Pricing and Access

Astra is rolling out in phases:

Initially to a limited set of organizations
Then to all ChatGPT Plus, Pro, Business, and Enterprise users over the coming days
Available via OpenAI API as gpt-6-astra, Microsoft Azure, and AWS Bedrock

API Pricing (Standard)

Mode	Input	Output
Standard	$10 / 1M tokens	$50 / 1M tokens
Fast mode	~$20 / 1M tokens	~$100 / 1M tokens

Fast mode delivers up to 2x speed at 2x price.

That's well above GPT-5.6 Terra's $2/$12 and Claude Opus 5's $5/$25, so Astra is priced as a frontier reasoning and automation model.

Enterprise admins can enable Astra per workspace; it's off by default at launch. Pro, Business, and Enterprise plans also get access to GPT-6 Astra Pro.

Early Real-World Examples (From the Community)

While I haven't had hands-on time yet, several developers have shared demos from the community:

3D design in Blender: Recreating a house from an image with full geometry, furniture, and appliances—renderable locally at 60fps.
Game design: One-shotting playable games with graphics and motion that go far beyond rudimentary prototypes.
Video to code: Taking a screen recording and recreating the interaction with accurate, runnable code.

These examples show Astra handling multi-step, visual, and interactive tasks that earlier models would've struggled to even plan.

What This Means for Your Stack

If you're building agentic workflows, here's how I'd think about Astra:

Use it for:

End-to-end computer tasks
Professional document/slide generation
Long coding sessions in Codex
Defensive cybersecurity (code review, patching)
Document-heavy pipelines (1M-token retrieval at 96.3% on MRCR v2)

Skip it for:

Routine bulk-text tasks where cheaper models suffice. At $10/$50 per million tokens, it's overkill for simple summarization or chat.

Watch out for:

Security-related pauses. If your workflow touches cybersecurity, budget for interruptions and read the system card before committing.

Final Take

GPT-6 Astra isn't trying to win every benchmark. It's making a clear bet: the next competitive frontier is agentic execution—models that can reliably use a computer, produce polished artifacts, and stay within authorized boundaries.

The saturated math and abstract-reasoning scores are impressive, but the number I'd act on is OSWorld 2.0 at 72.6% in 40 minutes. An agent that finishes real desktop work faster and more accurately than its predecessor is the practical difference for most teams.

Temper the "AGI" hype with two caveats:

The marquee ARC-AGI-3 figure was achieved using OpenAI's responses API harness, which changes two settings to better match real-world performance. Results may differ with standard evaluation setups.
On Humanity's Last Exam with tools, Astra actually trails Claude Fable 5.1 and Opus 5.

This is a strong, specialized model—not a clean sweep across every metric. But for devs building automation, professional tooling, or defensive security workflows, it's the most capable option OpenAI has shipped to date.

References

For more such developer content, click here

AI Coding Agents Need Sandboxes Before They Need Better Models

Shrestha Pandey — Sat, 05 Sep 2026 16:17:14 +0000

Last month I gave an agent full shell access on a side project, stepped away, and came back to find it had run npm install on a package I didn't recognize — something pulled from a typo-squatted namespace with a name close enough to fool it. Nothing bad happened, as far as I could tell. But I lost twenty minutes auditing my own machine instead of shipping anything, which is the opposite of what the tool was supposed to give me.

Claude and GPT-5-class models are genuinely solid at working through multi-step coding tasks now. The problem was that nothing sat between "the model decided to run a command" and that command actually executing, on my laptop, with my permissions.

Everyone wants to talk about which model reasons best. Almost nobody asks what happens the day the best-reasoning model is confidently wrong.

Two failure modes

Agents fail in ways that tend to get lumped together but really aren't the same thing.

One is a capability failure — bad logic, a misread requirement, a function that just doesn't do the job. Annoying, sure, but you read the diff, reject it, move on. Nothing's lost but time.

The other is an execution failure: the agent deletes something it shouldn't have, overwrites a .env file, pushes straight to main, pulls in a compromised dependency, or fires off a command whose effects land somewhere outside the project folder entirely. You often don't get a chance to catch this one before it happens, because the whole appeal of an "autonomous" agent is that it acts first and reports back after.

Better models shrink the first category. They barely touch the second. A more capable model can still hallucinate a destructive command with total confidence — arguably it does this more smoothly now, which if anything makes the mistake easier to trust and harder to notice.

What people are running

Cut through the marketing and most agentic coding setups fall into one of three buckets.

Straight in your shell, under your own user account. Quick to set up. Also means the agent inherits everything you have access to — SSH keys, cloud credentials sitting in ~/.aws, active browser sessions if it can reach them, write access across your whole filesystem.

Inside Docker, but usually with the project directory bind-mounted and no real limits on outbound traffic. An improvement, technically. Still not much of a wall if the container can talk to the internet freely and something manages to trick the agent into reaching out.

A proper ephemeral VM, the CI-style approach. Safest of the three, and also the one almost nobody bothers with day to day, because it's slower to wire up and adds friction to every iteration.

Most people land on the first option, because it's the one that works with zero extra setup. It's also the one offering the least protection.

Here's the part that doesn't get enough attention: the agent doesn't need bad intentions to cause damage. It just needs to read something bad. A poisoned README, a scraped answer from some forum, a dependency with a shady postinstall script — any of these can push an agent toward a command that looks perfectly reasonable to the model and completely wrong to you. Prompt injection through untrusted content isn't some far-off hypothetical for these tools. It's just what tends to happen once you hand a language model shell access and let it browse.

Smarter models don't fix this, they shift it

This is the counterintuitive bit. You'd expect better reasoning to lower risk across the board. Instead it just moves the risk somewhere else.

As models get better, teams reasonably let them run longer stretches without checking in. Early copilots suggested one line and paused. Current agents plan out a task, run through five or ten steps, and only surface once they think they're done — that's the entire selling point, less babysitting required.

But less babysitting means more real actions happen in the gap between human checkpoints. If step three out of ten goes wrong and nobody looks until step ten, you've now got nine additional automated actions building on top of a bad call before anyone catches it. A weaker model that got reviewed after every step would, in practice, have been the safer choice — even with worse reasoning.

So the pattern holds: model quality climbs, autonomy climbs with it, and the blast radius of any single mistake climbs too, unless something else is putting a ceiling on it.

What needs to be in place

A sandbox is more than tossing the process into Docker and moving on. Real containment needs several pieces working together.

Filesystem isolation that holds up. The agent should see only the project it's working on — not your home directory, not neighboring repos, not your dotfiles. Writes ideally land on an overlay or snapshot you can discard entirely if a session goes wrong.

Network access denied by default. This single change eliminates most exfiltration risk from prompt injection on its own. If the agent can't reach arbitrary hosts, it barely matters if something tries to trick it into trying.

Actual resource limits. CPU, memory, wall-clock time capped. A runaway loop shouldn't be able to fork-bomb a host or quietly run up a serious cloud bill while no one's watching.

Credentials that are scoped and short-lived. Not a master API key sitting in an environment variable for the whole session — a narrow token, issued right before it's needed, expiring soon after.

Logs kept somewhere the agent can't touch. Every command run, every file opened, recorded outside the sandbox itself, so if something goes wrong you can reconstruct it instead of guessing.

Firecracker microVMs, gVisor, and OCI containers locked down with tight seccomp profiles each handle part of this. What's missing is any of it being the default in the tools developers actually use. Right now it's an advanced setting most people skip, because skipping it saves one command and the risk feels abstract until it isn't.

This is a workflow decision

None of this argues against agentic coding tools, and it doesn't replace reviewing what they produce. It changes what that review is actually protecting. If an agent goes off track inside an isolated, network-restricted, disposable environment, the worst outcome is: task failed, discard the sandbox, try again. If it goes off track on your real machine, the worst outcome is something you're explaining to your team on Monday.

A setup worth aiming for, if you're adopting this seriously:

One disposable sandbox per task rather than per session, so nothing outlives its purpose
Every diff reviewed before merging, no "it's probably fine" exceptions
Network access off by default, opened per dependency only when there's a specific reason
Credentials issued just-in-time, scoped as tightly as the task allows
Command and file-access logs kept outside the sandbox regardless of outcome

That's more work up front than pulling an agent CLI and pointing it at a repo. It's also the gap between occasionally getting a bad diff and occasionally getting a security incident.

Which one matters more

Model providers will keep shipping better reasoning and longer context windows, and that's a good thing — this isn't an argument against it. But none of it touches the risk most teams are already carrying: agents with real execution power and nothing meaningful containing them.

Sandboxing doesn't show up on a leaderboard, so it gets a fraction of the attention model releases do. But it's the piece that decides whether handing an AI the ability to run commands turns into a genuine productivity gain or a liability sitting one bad prompt injection away from becoming your problem. Before picking which model to wire into an agent, it's worth working out what your setup actually does on the day that model is confidently wrong.

Kubeflow Just Graduated From CNCF — Here's What Changes

Shrestha Pandey — Fri, 28 Aug 2026 11:22:58 +0000

On August 17, 2026, the Cloud Native Computing Foundation announced that Kubeflow had reached Graduated status, its top tier of project maturity, shared with names like Kubernetes, Prometheus, and Envoy. If you've been running Kubeflow in production for a while, this might read as a formality. If you've been on the fence about adopting it, it's worth understanding why this milestone actually matters and where it leaves the project relative to the rest of the MLOps landscape.

What "graduated" means

CNCF projects move through three stages: Sandbox, Incubating, and Graduated. Getting to Graduated isn't just a matter of time in the ecosystem or GitHub star count, though Kubeflow has plenty of both, over 6,600 contributors across more than 1,000 organizations and north of 33,000 stars at the time of graduation. The bar includes things that are much harder to fake:

A completed third-party security audit
A documented, transparent governance model with a formal steering committee
Adoption of the CNCF Code of Conduct
A Core Infrastructure Initiative Best Practices badge, which checks for things like reproducible builds, vulnerability disclosure processes, and test coverage

In other words, graduation is CNCF's way of telling enterprise buyers: this project isn't going anywhere, and it's been vetted well enough that your security and compliance teams don't need to treat it as a science experiment.

That distinction matters more for Kubeflow than for a lot of graduated projects, because Kubeflow sits in a category — AI/ML infrastructure — that CNCF has historically been light on. It's one of the first AI-native projects to reach this tier, which says less about Kubeflow specifically and more about how young "cloud native AI" is as a formal category within CNCF's portfolio.

Why this is happening now

Kubeflow started in 2017 as an internal Google project — famously demoed with a hot-dog/not-hot-dog classifier by co-founder David Aronchick and colleagues — built to answer a fairly narrow question: how do you run TensorFlow training jobs on Kubernetes without reinventing scheduling, storage, and orchestration every time. Nine years later, the problem it addresses has expanded well past training jobs.

Model training used to be the whole story. Now teams need to move seamlessly between data preprocessing, experimentation notebooks, distributed training, fine-tuning, batch inference, and long-running model serving — often across multiple clouds or on-prem clusters for regulatory reasons. Doing all of that with a patchwork of point solutions creates real friction: different auth models, different observability stacks, different ways of expressing "give me 8 GPUs for 6 hours."

Kubeflow's pitch has always been that Kubernetes primitives — pods, custom resources, controllers — are a reasonable common substrate for all of that, if someone builds the right abstractions on top. Graduation is CNCF validating that the project has actually delivered on that pitch at a scale enterprises can trust.

What's actually in the box

If you haven't looked at Kubeflow recently, it's no longer a single monolithic install. The project is a collection of components that you can adopt individually or together, which is a big part of why it's found its way into so many different kinds of teams.

Training operators handle distributed training jobs across PyTorch, TensorFlow, XGBoost, and MPI. Instead of hand-rolling a StatefulSet and wiring up rank/world-size environment variables yourself, you define a PyTorchJob custom resource with a worker count and a container image, and the operator handles pod placement, restart-on-failure semantics, and networking between workers. It's the part of Kubeflow most teams touch first, because it replaces the most tedious boilerplate.

Katib does hyperparameter tuning and neural architecture search. You define a search space (learning rate, batch size, layer count, whatever you're sweeping) and an objective metric, and Katib runs a configurable number of trials in parallel using strategies like Bayesian optimization, Hyperband, or a straightforward grid search — then reports back which trial actually won. It's most useful once you've got a training pipeline stable enough to iterate on, rather than during initial model development.

Kubeflow Pipelines is the orchestration layer — it lets you define a multi-step workflow (pull data, validate it, train, evaluate, conditionally deploy) as a DAG in Python using the KFP SDK, and it compiles down to Argo Workflows under the hood. This is the component that turns "a notebook someone ran manually" into something that runs on a schedule, retries on failure, and produces an audit trail of exactly which data and code produced which model.

Notebooks gives you managed Jupyter environments with GPU access, persistent storage, and RBAC baked in, so a data scientist can spin up an environment with a specific CUDA version and a shared PVC without filing a platform ticket.

KServe, which graduated as its own separate CNCF project, handles model serving — including scale-to-zero for inference endpoints that see intermittent traffic, canary rollouts between model versions, and standardized inference protocols (V2/Open Inference Protocol) so your client code doesn't need to know whether the backend is a scikit-learn model or a large PyTorch service.

It also plays deliberately well with other CNCF projects rather than trying to replace them: Prometheus for monitoring, Istio for service-to-service traffic and mTLS, Kueue for job queuing and quota management across teams. That composability is part of the reason CNCF membership makes sense for Kubeflow in the first place — it was designed from the start to be one piece of a larger cloud native stack, not a walled garden.

Trying it locally

You don't need a GPU cluster to get a feel for the core workflow. A local kind cluster is enough to install Kubeflow Pipelines standalone and run a toy pipeline end to end:

# spin up a local cluster
kind create cluster --name kubeflow-demo

# install the Pipelines standalone deployment (not the full platform)
export PIPELINE_VERSION=2.3.0
kubectl apply -k "github.com/kubeflow/pipelines/manifests/kustomize/cluster-scoped-resources?ref=$PIPELINE_VERSION"
kubectl wait --for condition=established --timeout=60s crd/applications.app.k8s.io
kubectl apply -k "github.com/kubeflow/pipelines/manifests/kustomize/env/platform-agnostic-pns?ref=$PIPELINE_VERSION"

# wait for everything to come up, then port-forward the UI
kubectl port-forward -n kubeflow svc/ml-pipeline-ui 8080:80

From there, pip install kfp gets you the SDK to define a pipeline as plain Python:

from kfp import dsl

@dsl.component
def say_hello(name: str) -> str:
    return f"hello, {name}"

@dsl.pipeline
def hello_pipeline(name: str = "world"):
    say_hello(name=name)

Compile it with kfp.compiler.Compiler().compile(hello_pipeline, "pipeline.yaml") and upload the resulting YAML through the UI at localhost:8080, and you'll see the DAG, the run logs, and the artifact lineage for even this trivial example. It's a five-minute way to understand what the pipelines layer is actually doing before you commit to installing the full platform, which is a much heavier lift involving Istio, Dex for auth, and a fair amount of resource overhead.

What graduation changes in practice

For teams already running Kubeflow, not much changes overnight from a technical standpoint. The code doesn't suddenly get better on graduation day. What does change:

Procurement gets easier. A lot of platform teams have internal policies that gate adoption of open source infrastructure based on CNCF maturity level. Graduated status can unblock deployments that were previously stuck behind a security review or a "let's wait and see" decision from leadership.

Vendor commitment becomes more credible. Companies like Red Hat, Bloomberg, NVIDIA, LinkedIn, and Spotify have already built internal ML platforms on top of Kubeflow. Graduation signals to other vendors that investing engineering time in Kubeflow integrations — rather than building a proprietary equivalent — is a safer long-term bet.

The neutral-governance argument gets stronger. One of the recurring objections to any Google-originated project is the fear that a single vendor controls the roadmap. A formal steering committee with defined governance, verified by CNCF's audit process, is a direct answer to that concern.

Where it fits against alternatives

Kubeflow isn't the only option for running ML on Kubernetes, and it's worth being honest about that. Ray and Ray Serve are strong if your workloads lean heavily toward distributed Python and you don't need the full pipeline-orchestration layer. MLflow remains popular for experiment tracking without the operational overhead of running a full Kubernetes-native platform. Managed offerings from the big three clouds solve a lot of the same problems if you're comfortable trading portability for convenience.

Here's roughly how they compare on the dimensions that tend to actually drive the decision:

	Kubeflow	Ray / Ray Serve	MLflow	Managed cloud (SageMaker, Vertex, Azure ML)
Scope	Full lifecycle: data prep → training → serving	Distributed compute + serving	Experiment tracking + model registry	Full lifecycle
Multi-cloud / on-prem portability	High — Kubernetes-native	Medium — needs a Kubernetes or VM backend	High — mostly backend-agnostic	Low — locked to one cloud
Operational overhead	High (Istio, Dex, multiple CRDs)	Medium	Low	Low (managed by vendor)
Best fit	Regulated, multi-environment enterprises	Python-heavy distributed workloads, RL, LLM serving	Teams that just need tracking, not orchestration	Teams fully committed to one cloud
Governance	CNCF-graduated, vendor-neutral	Backed by Anyscale	Backed by Databricks	Single-vendor

None of these rows are meant to declare an outright winner, they mostly just make explicit the tradeoff that's already implicit in each tool's design. Ray optimizes for developer velocity on distributed Python; Kubeflow optimizes for portability and governance at the cost of operational complexity; managed services optimize for "someone else runs this," which is a perfectly reasonable thing to want until portability becomes a hard requirement.

Kubeflow's differentiator is really about scope and portability: if you need one platform that spans data processing through serving, that has to run identically across AWS, GCP, on-prem, and air-gapped environments for regulatory reasons, the calculus tilts toward Kubeflow specifically because it's Kubernetes-native rather than cloud-native-to-one-cloud. That's a narrower use case than "everyone doing ML," but it's exactly the use case a lot of regulated enterprises — finance, healthcare, government contractors — actually have.

Should this change what you do next quarter?

If you're already running Kubeflow, graduation is a good moment to revisit your internal risk assessment and possibly simplify the approval story for expanding its footprint. If you're evaluating platforms and portability or multi-cloud/on-prem flexibility matters to you, it's now much easier to make the case that Kubeflow is a safe long-term bet rather than a project you'd have to migrate off of in three years. If your workloads are firmly single-cloud and you're happy with a managed service, graduation doesn't really change that calculus — the managed offering still wins on operational simplicity.

The bigger signal here is about CNCF's own trajectory. AI infrastructure has been conspicuously underrepresented in CNCF's graduated tier relative to how much of the industry's engineering effort is now going toward AI workloads. Kubeflow being one of the first to cross that line suggests the foundation is actively building out that category, and it probably won't be the last AI-focused project to get there this year.

TypeScript 7.0 Is Rewriting the Compiler in Go

Shrestha Pandey — Tue, 25 Aug 2026 18:00:47 +0000

For most of its history, TypeScript has been written in TypeScript. The compiler, the language service, the checker — all JavaScript, all running on a single thread inside Node.js. That's changed now. TypeScript 7.0, shipped by Microsoft on July 8, 2026, replaces that entire implementation with a native compiler written in Go, developed under the internal codename Corsa.

There's no new operator, no new utility type, no new flavor of decorators to learn. The entire pitch is architectural. A compiler that runs as compiled native code instead of interpreted JavaScript, with real multi-threaded parallelism instead of a single-threaded event loop. If you've ever watched tsc --noEmit grind through a large monorepo, this release is aimed squarely at you.

Here's what actually changed, why Microsoft picked Go over Rust or its own C#, and what it means for your day-to-day workflow.

Why rewrite the compiler at all

The JavaScript-based compiler had hit a structural ceiling. Type-checking is CPU-bound and highly parallelizable in theory — different files and different parts of a project can be checked independently — but a single-threaded interpreted runtime can't take advantage of that. Every extra core sitting idle on a CI runner was wasted, and V8's JIT overhead only compounds on cold starts, which matter a lot for editor tooling and CLI invocations that start fresh constantly.

The TypeScript team weighed C#, Rust, and Go before settling on Go. Lead architect Anders Hejlsberg explained the reasoning as choosing the lowest-level language that still delivered full native-code support across every platform TypeScript needs to run on, with strong built-in support for concurrency. Go's goroutines and channels map cleanly onto the "check many files in parallel, then merge results" problem that type-checking actually is, without the steeper learning curve or borrow-checker overhead that a Rust port would have introduced for a team migrating an existing, enormous codebase.

Crucially, the Go port wasn't written from a blank page with a redesigned architecture. The team ported the existing compiler as faithfully as possible specifically to keep results consistent between the old and new implementations rather than risk subtle type-checking differences creeping in.

The performance numbers

The headline figure Microsoft is quoting is an 8x to 12x speedup on full builds for large, real-world projects, driven by native-code execution, shared-memory multithreading, and a set of targeted optimizations layered on top.

Independent benchmarks back this up with concrete examples rather than just multipliers:

A full type-check of the VS Code codebase dropped from over two minutes to about ten seconds.
Editor startup time for VS Code's language service — the delay before autocomplete and error-checking are usable — fell from roughly 9.6 seconds to about 1.2 seconds.
Memory usage dropped as well, with reported reductions somewhere in the 6% to 26% range depending on project size.
At Slack, engineers had previously been unable to run a full type-check locally at all and offloaded it to CI. With TypeScript 7, that check runs on a developer's laptop again.
At a glance — TS 6.0 vs. TS 7.0:
VS Code, full type-check: ~125s → ~10.6s (~12x faster)
VS Code, language service ready: ~9.6s → ~1.2s (~8x faster)
Typical large monorepo, full build: 8x–12x faster overall
Peak memory usage: 6%–26% lower
They're the kind of number that changes how a team works day to day: PRs that used to wait on a slow CI type-check come back faster, and the "let me just wait for the editor to catch up" pause before you start typing mostly disappears.

What's actually new under the hood

Native multithreading, with knobs to control it

The old compiler had no real concept of parallel type-checking; a single check ran on a single thread, full stop. TypeScript 7.0 introduces genuine shared-memory multithreading, along with flags to tune it:

# Use multiple type-checking workers
tsc --checkers 4

# Run multiple project-reference builders in parallel (monorepos)
tsc --builders 4

# Disable parallelism entirely — useful for debugging or
# comparing behavior against older TypeScript versions
tsc --singleThreaded

More checkers generally means faster type-checking at the cost of higher memory usage, so the right setting depends on your machine and your project's shape. For monorepos using project references, --builders lets multiple project builds run concurrently instead of serially, which is where a lot of the biggest real-world wins show up. Microsoft's own guidance is to be careful combining --checkers and --builders together, since the two multiply the number of active workers rather than add to it.

A new binary, not just a new flag

The Go compiler ships as a separate binary, distributed during the preview period as @typescript/native-preview on npm, with nightly builds available well before the tool was folded into the mainline typescript package. Getting started is close to a drop-in swap for most projects:

npm install -D typescript@latest

Teams migrating incrementally can install the native binary alongside the existing tsc and run both side by side to diff diagnostics before fully cutting over — which is exactly what Microsoft recommends rather than a hard, all-at-once switch. In practice that's a small, reversible change to your scripts rather than a rewrite of your build:

// package.json
{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "typecheck:native": "tsgo --noEmit --checkers 4"
  }
}

Run typecheck:native in CI alongside the existing script for a few weeks, diff the output, and once the diagnostics line up you can retire the old script and point your build pipeline at the native binary.

Editor tooling gets the same treatment

The language server, the part responsible for autocomplete, hover types, and inline errors in your editor, was rewritten too, built on a new Language Server Protocol foundation so it isn't tied to VS Code specifically. Any LSP-compatible editor should be able to pick it up. VS Code users can currently opt in through the TypeScript Native Preview extension, and Visual Studio will auto-enable TypeScript 7 based on workspace configuration. Internally, Microsoft has reported a 20x reduction in failing language server commands compared to TypeScript 6.0, a proxy for how often the old server would time out, hang, or return stale results on large projects.

What developers actually gain

Strip away the architecture talk and the concrete wins are:

Faster feedback loops. Full project checks that took minutes now take seconds, which changes how often you're willing to run them.
Snappier editors on large codebases. Faster startup and lower latency on autocomplete and diagnostics, particularly noticeable on monorepos and codebases in the tens-of-thousands-of-files range.
Cheaper CI. Type-checking is frequently one of the slower steps in a JavaScript/TypeScript pipeline; an 8–12x reduction there has a direct, measurable effect on CI minutes and pipeline duration.
Better use of the hardware you already have. Multi-core machines that were previously mostly idle during a type-check now get used, via --checkers and --builders.
Lower memory pressure, which matters both on constrained CI runners and on developer laptops running an editor, a dev server, and a type-checker at once. ## What to know before upgrading

This is still a young, fast-moving migration, and there are real gaps worth knowing about before you commit a team to it:

The programmatic API is unstable. If you have build tooling, linters, or custom scripts that call into the TypeScript compiler API directly rather than shelling out to tsc, that surface hasn't stabilized yet. Microsoft has indicated a stable programmatic API is targeted for TypeScript 7.1, not 7.0.
The plugin and third-party tooling ecosystem is still catching up. Bundler integrations, editor plugins beyond the officially supported ones, and any tool that shells out to or embeds the old JavaScript compiler may need updates.
Compatibility is strong but not perfect. In testing against large sets of real-world projects, TypeScript 7 flagged errors consistent with TypeScript 6 in the overwhelming majority of cases, but not literally all of them — a small number of projects saw new or different diagnostics surface, which is worth budgeting time to review if you're on a large codebase.
This is a performance release, not a language release, despite the major version bump. If you're expecting new syntax or type-system features, they're not the point of 7.0. ## Should you upgrade now

For most teams, yes, with the incremental path Microsoft is recommending rather than a flip of the switch. Install the native compiler alongside your existing setup, run both against your codebase, diff the diagnostics, and confirm nothing unexpected shows up before replacing tsc in CI. If your project leans heavily on the programmatic compiler API for custom tooling, it's reasonable to wait for 7.1 before migrating that part of your stack, while still adopting the faster CLI and editor experience today.

The bigger story here isn't really about TypeScript specifically. It's part of a broader pattern across the JavaScript ecosystem — Rust-based bundlers, a Rust rewrite of pnpm, Bun's own move from Zig toward Rust — where tools that spent years as pure JavaScript are being rebuilt in compiled languages once JavaScript's single-threaded, interpreted nature becomes the actual bottleneck. TypeScript's compiler was arguably the biggest and most consequential piece of that puzzle still standing, and now it isn't.

For more such developer content, visit: vickybytes.com

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