DEV Community: Shrestha Pandey

Why Is My Code Slow? Big-O Explained With Real Timings

Shrestha Pandey — Sun, 11 Oct 2026 05:15:57 +0000

Almost every developer knows Big-O. Many can even say what O(n²) means. But very few have watched the real difference happen on their own machine.

So I ran a small experiment with one simple problem, three ways to solve it, and a stopwatch. The results were bigger than I expected, and I think they explain Big-O better than any textbook.

The problem

You have a list of numbers. Is any number in the list repeated?

This is a real problem which looks like:

checking if two users signed up with the same email
finding duplicate order IDs in a file
making sure every ticket number in a batch is unique

To make the test fair, I used the hardest case: a list with no duplicates at all. That way, every method has to look at the whole list before it can say "no duplicates."

Three ways to solve it

Think of a room full of people, and you want to know if two of them share the same name.

Method 1: Ask everyone about everyone (nested loops).
You take person 1 and compare them with everybody else. Then person 2 with everybody else. And so on. It is easy to understand, and it is how most of us would write it first.

def has_duplicates_nested(items):
    n = len(items)
    for i in range(n):
        for j in range(i + 1, n):
            if items[i] == items[j]:
                return True
    return False

Method 2: Sort first (sorting).
You line everyone up in alphabetical order. Now two people with the same name must be standing next to each other. You only have to check neighbors.

def has_duplicates_sorted(items):
    s = sorted(items)
    for i in range(len(s) - 1):
        if s[i] == s[i + 1]:
            return True
    return False

Method 3: Keep a notebook (set).
You walk through the list once. For each person, you check your notebook: "Have I seen this name?" If yes, duplicate found. If no, write it down.

def has_duplicates_set(items):
    seen = set()
    for x in items:
        if x in seen:
            return True
        seen.add(x)
    return False

What Big-O says

Big-O tells you how the work grows when the list gets bigger.

Method	Big-O	What it means
Nested loops	`O(n²)`	Make the list 10× bigger, and the work becomes about 100× bigger
Sorting	`O(n log n)`	Make the list 10× bigger, and the work becomes a bit more than 10× bigger
Set (notebook)	`O(n)`	Make the list 10× bigger, and the work becomes about 10× bigger

On paper, these look like small differences. Let's see what they look like on a real computer.

The results

I ran this in Python 3.13 on a normal x86-64 machine. Each number is the best of 3 runs (the 20,000 and 40,000 nested runs are single runs, because they take so long).

List size	Nested loops	Sorting	Set
1,000	0.031 s	0.00019 s	0.00007 s
10,000	2.02 s	0.0019 s	0.0008 s
100,000	skipped	0.024 s	0.013 s
1,000,000	skipped	0.39 s	0.29 s

I skipped nested loops at 100,000 and 1,000,000 on purpose. You'll see why in a moment.

Here is the same data as a picture. Both axes use a log scale, so each step up is ten times bigger. The dashed line is my estimate for nested loops at sizes I didn't wait for.

Result 1: At just 10,000 items, nested loops is already about 2,500 times slower

At 10,000 items, the set finished in under a millisecond. The nested loops took over 2 seconds.

That is roughly 2,500 times slower, for a list that is small by real-world standards. 10,000 rows is a tiny table.

Result 2: Doubling the list makes nested loops about 4 times slower

This is the O(n²) signature. I ran nested loops at a few more sizes to see the curve:

List size	Nested loops time	Compared with previous row
10,000	2.0 s
20,000	7.9 s	about 4× slower
40,000	36.6 s	about 4.6× slower

Every time the list doubled, the time went up about four times. That is exactly what n² predicts: double the input, and you get 2 × 2 = 4 times the work.

Result 3: What would 1,000,000 items cost?

I didn't run it, because I didn't want to wait. But we can estimate using the curve above. At 40,000 items the nested loops needed 36.6 seconds. A list of 1,000,000 is 25 times longer, and n² means 25 × 25 = 625 times the work:

36.6 s × 625 ≈ 22,800 seconds, or about 6 hours

(This is my estimate from the measured curve)

The set version did the same job in 0.29 seconds.

What about sorting vs the set?

Both are fast, and the gap between them is small: at 1,000,000 items, sorting took 0.39 s and the set took 0.29 s.

On paper, the set is O(n) and sorting is O(n log n), so the set should pull ahead as lists grow. It does, but slowly, because the log n part grows very gently.

This is a useful lesson: not every Big-O gap is a disaster. The jump from n² to n log n is huge. The jump from n log n to n is small. Don't lose sleep over the second one until you have measured that it matters.

Why was the nested version so slow?

Count the comparisons. For a list of n items, nested loops make about n × (n − 1) / 2 comparisons:

List size	Comparisons
1,000	about 500 thousand
10,000	about 50 million
1,000,000	about 500 billion

Each time the list got 10× bigger, the number of comparisons got about 100× bigger. At a million items, that is half a trillion comparisons to find out that nothing is repeated.

The set avoids this by trading a little memory for speed. It remembers what it has seen, so each new item needs only one quick lookup instead of a trip through the whole list.

Three lessons I took from this

1. Small test data hides bad code.
At 1,000 items, even the slow method finished in 0.03 seconds. It looked fine. If you only test on a small sample, O(n²) code passes review and breaks in production, when the data grows 100 times.

2. Look for a loop inside a loop.
The fastest way to spot trouble is a loop that contains another loop over the same data. Also watch for hidden loops: in Python, x in some_list is itself a loop. Putting it inside a for loop quietly gives you nested loops.

3. A set (or dictionary) is often the cheapest upgrade.
"Have I seen this before?" is one of the most common questions in code. A set answers it in roughly one step, no matter how big it is. Many slow programs get fast just by swapping a list for a set.

Try it yourself

The whole experiment is one small file. Save it as bench.py and run python3 bench.py. It only needs Python.

Your numbers will be different, because every computer is different. But the shape will be the same: nested loops climbing like a cliff, and the other two staying flat and low.

Try changing the sizes. Try a list that does have duplicates near the start and see how the nested version suddenly gets lucky. Experiments like this teach more than any chart.

Quick cheat sheet

If you see...	It is probably...	Be careful when...
One loop over the data	`O(n)`	rarely a problem
Sorting the data	`O(n log n)`	rarely a problem
A loop inside a loop	`O(n²)`	data can reach tens of thousands of rows
`x in list` inside a loop	`O(n²)` in disguise	you can swap the list for a set

What to remember

Big-O is all about knowing, before the data grows, whether your code will still be fast when it does.

At 1,000 items, all three methods looked the same. At 40,000, one of them took 36 seconds. At a million, it would take hours.

That is why people care about Big-O.

For more such developer content, visit

How to Undo Common Git Mistakes Without Panic

Shrestha Pandey — Sat, 10 Oct 2026 05:04:04 +0000

Everyone makes mistakes in Git. Like committing to the wrong branch, writing a bad message, or deleting something by accident. The good news is that Git keeps a lot of history, so most mistakes can be fixed.

In this post, I will go through seven common mistakes and the commands that fix them. For each one, I will say whether the fix is safe or if it can delete work.

1. You wrote a bad commit message

If you have not pushed the commit yet, you can change the message of the last commit:

git commit --amend -m "Better message here"

This replaces the last commit with a new one. If you already pushed the commit, avoid this. Changing pushed history causes problems for other people on the team.

2. You committed too early

Suppose you made a commit, but you forgot a file, or you want to change the code a bit more. Undo the commit and keep your changes:

git reset --soft HEAD~1

This removes the last commit, but your changes stay staged, so you can edit and commit again.

Here is how the three types of reset differ:

--soft removes the commit and keeps your changes staged.
--mixed (the default) removes the commit and keeps your changes, but unstaged.
--hard removes the commit and deletes your changes. Be careful with this one.

3. You staged a file by mistake

You ran git add on a file that should not be in the commit. Unstage it:

git restore --staged filename.js

The file stays changed on your disk. It is just no longer staged. This is safe.

(In older versions of Git, you may see git reset HEAD filename.js for the same task.)

4. You want to throw away changes in a file

You edited a file, and now you want it back to the last committed version:

git restore filename.js

Warning: This cannot be undone. Git has no copy of changes you never committed or staged. Check with git diff first if you are not sure.

5. You committed to the wrong branch

This often happens when you forget to create a new branch. Say you made a commit on main, but it should be on a new branch called feature.

First, create the new branch at your current commit. This keeps the commit safe:

git branch feature

Next, move main back to match the remote version:

git reset --hard origin/main

Last, switch to your new branch:

git switch feature

Your commit is now on feature, and main is clean. Note that git reset --hard deletes any uncommitted changes, so commit or stash them first.

6. You pushed a bad commit

When a commit is already pushed and shared, do not rewrite history. Use revert instead:

git revert <commit-hash>

This creates a new commit that does the opposite of the bad one. The history stays honest, and nobody's work breaks. This is the safe way to undo shared work.

You can find the commit hash with git log --oneline.

7. You lost commits or deleted a branch

This is where reflog helps. Git records every place HEAD has been, even after a hard reset or a deleted branch:

git reflog

You will see a list like this:

a1b2c3d HEAD@{0}: reset: moving to HEAD~2
e4f5a6b HEAD@{1}: commit: Add login form
c7d8e9f HEAD@{2}: commit: Add user model

Find the commit you want back, and create a branch from it:

git branch recovered e4f5a6b

Your work is back on a new branch called recovered.

Reflog entries do not last forever. By default, Git keeps them for about 30 to 90 days, so recover lost work soon after it happens. Also, reflog only tracks commits. It cannot bring back changes that were never committed.

A few safety habits

These small habits make mistakes less painful:

Commit often. A commit is a safety point, because uncommitted work is the hardest to recover.
Check before you delete. Run git status and git diff before commands like reset --hard or restore.
Make a backup branch. Before a risky command, run git branch backup.
Avoid force push on shared branches. If you must, use git push --force-with-lease. It refuses to overwrite work you have not seen.
Read the command first. If you do not know what a command does, check the docs with git help <command>.

Quick reference

Problem	Command
Bad last commit message	`git commit --amend -m "..."`
Undo last commit, keep changes	`git reset --soft HEAD~1`
Unstage a file	`git restore --staged <file>`
Discard changes in a file	`git restore <file>`
Undo a pushed commit	`git revert <hash>`
Find lost commits	`git reflog`

Final thoughts

Git feels difficult at first, but it is built to protect your work. Most of the time, a commit you made is still there, even if it looks gone. When something goes wrong, stop, run git status and git reflog, and think before you run the next command.

Which Git mistake have you made the most? Tell me in the comments.

Hacktoberfest 2026: The Complete Guide (New Rules, Dates, Swag, and How to Join)

Shrestha Pandey — Mon, 28 Sep 2026 13:37:24 +0000

If you remember Hacktoberfest as "open four pull requests, get a T-shirt," that version is over. Hacktoberfest 2026 is a different event, and a lot of guides online are still out of date. This one covers what changed, what is confirmed, what is still unannounced, and how to get the most out of
October.

Last updated: September 28, 2026. Details are still being published, so check the official links at the bottom.

Quick facts
What changed in 2026 (and why)
Who can participate
Ways to take part
The online calendar
Swag: what you can and can't get
How to host a Fest
Contributing to open source anyway
A one-week starter plan
FAQ
Official sources

1. Quick facts


Runs	Throughout October 2026
Organizers	Major League Hacking (MLH) and DEV, in partnership with DigitalOcean
Theme	Open-source AI and open-weight models ("AI belongs to everyone")
Format	300+ in-person events ("Fests") plus online events
PR counting	No
Age	13 and older, subject to U.S. export controls and embargo restrictions
Cost	Global Hack Week: free to register. Check each Fest and challenge page for its own terms.

2. What changed in 2026 (and why)

Hacktoberfest started in 2014 at DigitalOcean with a simple challenge: open four pull requests in October and earn a T-shirt. It introduced a lot of people to open source.

Over time the format created a problem. Maintainers were flooded with low-effort, box-checking pull requests, and AI tools made it trivial to generate more. The organizers say the event meant to help maintainers had started to burden them.

So for 2026:

PRs are not counted toward participation or rewards.
The focus is on learning and building with open-source AI. The organizers give examples like writing your first open-source skills.md, building an open-source agent, or fine-tuning an open-weight model.
The main format is community events, plus an online program.
MLH and DEV are now full partners with DigitalOcean in running it.

Important: contributing to open source is still encouraged. It just isn't what earns Hacktoberfest swag anymore.

3. Who can participate

Anyone 13 or older, worldwide, subject to U.S. export controls and embargo restrictions. Swag shipments and Fests also exclude locations embargoed or sanctioned by the U.S.

For the online Global Hack Week (below), registration asks you to confirm you're over 18 or have a parent's permission.

4. Ways to take part

Attend an in-person Fest

A Fest is an official in-person event of up to 12 hours. Use the Find a Fest page to search by name, city, or country.

	Hack Day	Meet Up
Style	Structured mini hackathon building open-source AI projects	Talks, workshops, panels, social discussion
Swag	Yes	Yes (stickers, T-shirts, postcards)
Prize categories	Yes, plus DEV Badges	No
Organizer food/drink reimbursement	Yes	No

Join the online program

For people who can't reach a Fest, there is an online event running throughout October (see the calendar below).

Host your own Fest

Covered in section 7.

5. The online calendar

Confirmed on official pages:

Event	Dates	Notes
Weekend Challenge (DEV)	Starts October 2	Short-form kickoff challenge, cash prizes
Open-Source AI Challenge: Week 1	Starts October 5	Cash prizes
Week 2	Starts October 12	Cash prizes
Week 3	Starts October 19	Cash prizes
Week 4	Starts October 26	Cash prizes
Global Hack Week: Hacktoberfest (MLH)	October 9, 12:00 PM EDT to October 15, 1:00 PM EDT	Online, free registration

What Global Hack Week includes, per its event page: daily live-streamed workshops on Twitch, mini-events in the MLH Community Discord, and challenges (social, technical, and design) where you earn points, including a point each time you check in to a live session. Registration asks for a GitHub username (or "N/A").

Not yet announced: the prompts for each DEV challenge, prize amounts, number of winners, and judging criteria. Each challenge page publishes its
own terms when it goes live. Read those before building anything for a prize.

Time zones: convert times yourself. For example, Global Hack Week starts at 16:00 UTC on October 9, which is 9:30 PM in India (IST).

6. Swag: what you can and can't get

Item	Who gets it
T-shirts	In-person Fests only, sent to organizers who distribute them at their discretion. Not guaranteed, and online participants are not eligible.
Stickers (MLH, DigitalOcean)	Sent to every in-person Fest
Swag Envelope	Online participants who complete participation milestones. Contains custom stickers and other envelope-friendly items. Milestones not yet published.
Postcards	Listed in the FAQ for Meet Ups. Fest packs otherwise list MLH and DigitalOcean stickers and T-shirts.

Swag Envelopes ship after Hacktoberfest ends and should reach most destinations within 30 to 60 days.

To be eligible for physical swag from Global Hack Week, the registration form says you must fill out MLH's shipping address form.

7. How to host a Fest

You don't need a big team. The organizers say a meetup group, university club, or a few coworkers with a conference room is enough.

What organizers get: stickers and T-shirts for participants, programming support, and a listing in the searchable gallery on hacktoberfest.com, promoted through MLH and DEV channels.

Requirements:

A safe, accessible in-person venue for 3 to 12 hours, with reliable Wi-Fi, power outlets, seating, and AV equipment
MLH's OrganizerHQ for registration and check-in (Hack Days also use it for project submissions and judging)
After the event: high-resolution photos, verified check-in data, winner records, and food/beverage receipts (Hack Days)

Funding: Hack Days can get reimbursement for approved food and drink, up to a cap. Meet Ups and corporate partner hosts aren't eligible.

Timing: apply through the host portal. Applications are reviewed on a rolling basis, typically confirmed in under a week. The organizer guide explains the process. September is "Preptember," the planning period before hacking begins in October.

8. Contributing to open source anyway

This section is general open-source advice, not official Hacktoberfest guidance.

The official FAQ says open source runs all year and you can start any time. If you want to contribute this month, do it in a way maintainers appreciate:

Pick the right project

Recent commits and responsive maintainers
A CONTRIBUTING.md you can actually follow
A license file
Labels like good first issue or help wanted

Pick the right issue

Still open, and not assigned to someone else
No competing pull request already linked
Small enough to finish and test

Before writing code

Read CONTRIBUTING.md, the code of conduct, and the PR template.
Reproduce the problem yourself.
Comment on the issue to say you'd like to work on it and how you plan to approach it. Some projects require assignment first.
Search closed issues and PRs to avoid duplicating work.

In your pull request

Keep it focused on one problem.
Add or update a test that fails before your change and passes after it.
Explain what you changed and how you verified it.
Follow the project's AI-use policy if it has one. Don't submit code you can't explain.

Low-noise ways to help: improving documentation, fixing broken links, adding tests, triaging or reproducing bug reports, and translating docs.

9. A one-week starter plan

This section is general open-source advice, not official Hacktoberfest guidance.

Day	Goal
1	Create a DEV account, register for Global Hack Week, join the MLH Discord, submit your shipping address
2	Follow each DEV challenge page and note the dates
3	Pick a lane: agent, skill, model fine-tuning, evaluation, or docs
4	Set up a public repo with a license and README
5	Build the smallest working version
6	Add tests and setup instructions
7	Write it up and share it (a DEV post works well)

Don't build a "prize entry" before the prompt is published. Build a reusable project skeleton instead.

10. FAQ

Does Hacktoberfest 2026 count pull requests?
No. The official FAQ says the event has moved away from counting them.

Is Hacktoberfest 2026 free?
Global Hack Week registration is free. Fests and DEV challenges have their own terms, so check each event page.

Do I get a T-shirt if I join online?
No. Online participants aren't eligible for T-shirts.

How do I get swag online?
Online participants can earn an official Swag Envelope by completing participation milestones, which haven't been announced yet. Global Hack Week registration also asks you to submit a shipping address for stickers and swag. Check the Global Hack Week page for what's offered.

Can I join without attending a Fest?
Yes, via the online program.

Is there an official list of participating repositories?
None has been announced. Since PRs aren't the reward mechanism this year, don't expect one.

Do I need a GPU?
Not for everything. Docs, tests, evaluation tools, and small fine-tuning experiments can run on a normal laptop, but large model work may need more hardware.

Are the cash prizes confirmed?
The DEV hub labels all five challenges as having cash prizes. Amounts haven't been announced.

11. Official sources

For more such informational developer content, visit

GitHub Just Killed SHA-1 Over HTTPS

Shrestha Pandey — Sun, 27 Sep 2026 19:05:52 +0000

On September 15, 2026, GitHub turned off SHA-1 for HTTPS and TLS on github.com and its CDNs. They had been warning about it since April. If your client can't do a TLS handshake without SHA-1, you now get a connection error.

I'll skip the history lesson on SHA-1. What I want to cover is why this took until 2026 to finally happen, and how to check your own setup first.

Why was SHA-1 still around

TLS handshake is the part where your client and github.com agree on how to verify the certificate. It has nothing to do with Git's own object hashing, which is a separate, much slower migration to SHA-256 that most repos haven't touched yet.

Old clients kept SHA-1 alive in that handshake. GitHub kept SHA-1 working in TLS for years so those clients wouldn't just stop connecting.

The rollout went like this:

April 20, 2026: GitHub announced the change and warned about a brownout coming
July 14, 2026: an 18-hour brownout, 00:00 to 18:00 UTC, where SHA-1 was turned off just long enough for people to notice
September 15, 2026: SHA-1 turned off for good

A ten-second test you can run right now

GitHub had already disabled SHA-1 on github.dev early, so you can use it as a canary:

curl -v https://github.dev 2>&1 | grep -i "SSL connect\|handshake"

A clean connection means your TLS stack is fine. A handshake error means you were already going to break on the real deadline, and now you know early.

Run this everywhere that talks to GitHub, especially:

CI runners, especially self-hosted ones with old base images
servers that pull from GitHub unattended, deploy scripts, cron jobs
internal tools hitting the GitHub API directly instead of through an SDK

What actually broke

Affected: github.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, and partner CDNs. Not affected: GitHub Enterprise Server, the self-hosted version. If your org runs GHES, none of this touches you.

Inside that affected scope, the failures came from outdated crypto libraries: old curl/libcurl, unpatched .NET Framework builds, stale Python ssl modules, Alpine Docker images whose openssl never got bumped. Browsers have supported modern certs for almost a decade, so regular users on anything recent never noticed.

Most of the people who got hit were running infrastructure they'd forgotten about.

If it broke for you

The fix is dull, in a good way:

Update your TLS library, openssl, libcurl, whatever your runtime uses
Rebuild the CI base image rather than patching it. If it's old enough to hit this, other things on it are stale too
Run the github.dev check again to confirm

If you're stuck on something you truly can't update, some locked-down embedded box, there's no workaround here. GitHub isn't turning SHA-1 back on. The real fix is getting off that system.

The pattern worth remembering

Announce early. Run a scoped brownout as a fire drill. Give people a canary URL so they can check themselves. Then cut it for real. Most companies skip straight to a changelog post and hope nobody's affected. That's probably why so few people noticed this happening in real time. The brownout did its job.

Go run that curl command against github.dev on whatever CI box you haven't looked at lately. It's probably fine. But "probably" is exactly why you should check.

For more such articles, click

Jev vs. LLMs: What Happens When You Strip Text Generation Out of a Language Model

Shrestha Pandey — Wed, 23 Sep 2026 18:48:05 +0000

If you spent any time on AI, Twitter/X or Hacker News around September 15, 2026, you probably saw the word "Jev" on your feeds without much context. It's the first public model from a new startup called TypeSafe AI, and it's built around a genuinely different premise, i.e, what if a model never generated a single word of text?

I went and read the primary sources like TypeSafe's own announcement post, the LangChain integration writeup, and the surrounding community discussion, so you don't have to reconstruct the story from screenshots. Here's what Jev is, how it differs architecturally from the LLMs we all use daily, and where it does (and doesn't) make sense to reach for it.

The one-sentence pitch

TypeSafe's founder, Diogo Almeida, a former OpenAI researcher who worked on the RLHF methods behind ChatGPT, frames Jev as "a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out." You give it a state (context) and a set of typed questions, and it returns calibrated probabilities in a single forward pass.

TypeSafe calls this category of model a "System 1" model, borrowing Daniel Kahneman's fast/slow-thinking framing: LLMs do deliberate, sequential "System 2" reasoning; Jev does fast, intuitive "System 1" pattern-matching, packaged as software-callable structured output.

What's different architecturally

The core distinction is the output mechanism.

Autoregressive LLMs generate one token at a time, each conditioned on everything before it. That's why a long response takes longer than a short one, why streaming exists, and why a single "yes/no" answer still costs you a forward pass per token even when the model could've committed to an answer after the first few.

Jev doesn't do that. According to TypeSafe, it uses a non-autoregressive architecture with a parallel sampler — it produces every requested output simultaneously in one pass, regardless of how many questions you ask about the same state. Response times land in the 70–500ms range, versus the 3–329 seconds TypeSafe cites for frontier LLMs on comparable tasks (their own benchmark reference is here).

Independent speculation about the underlying architecture (notably a post from someone who ran the question through a paper-search tool) suggested Jev looks like a large schema-conditioned bidirectional encoder with parallel label-query heads, scaled well past typical classifier sizes, rather than anything exotic. TypeSafe hasn't published weights or a paper, so that's an educated guess from public behavior, not confirmed architecture.

The API surface: state + questions

Instead of a chat completions endpoint, Jev's API takes a state and a dictionary of questions, each typed as one of three kinds:

noul — yes/no, returns a probability the statement is true
choice — pick from a fixed set of options, returns per-option probabilities plus overall confidence
score — rate against ordered levels (low/medium/high), returns a continuous score and confidence A minimal request looks like this:

{
  "model": "jev-latest",
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

And the response is exactly what you'd want to branch on in application code:

{
  "is_urgent": {
    "type": "noul",
    "noul": 0.999
  }
}

Crucially, you can pack multiple questions into one request against the same state, and because sampling is parallel, adding more questions barely moves latency. That's a meaningfully different cost model than an LLM, where every additional thing you ask for costs proportional generation time.

Training: RLCD instead of RLHF/RLVR

LLMs today are typically post-trained with RLHF (optimizing for what human raters prefer) or RLVR (optimizing for programmatically verifiable rewards — math, code execution, etc.). TypeSafe describes Jev's training method as Reinforcement Learning for Calibrated Decisions (RLCD) — optimizing specifically for epistemically honest probability estimates on classification-shaped tasks, rather than for text a human would rate highly.

This is important because LLMs are notoriously bad at expressing calibrated uncertainty even when explicitly prompted to. A model that's actually right 95% of the time but doesn't reliably signal when it's in the wrong 5% is dangerous to automate around. TypeSafe's pitch is that Jev's probabilities are meaningfully calibrated which is a stronger and more falsifiable claim than "the model said 87% so trust it."

The "no hallucination" claim, and why it's true by construction

TypeSafe claims Jev can't hallucinate and never produces a type error. This might sound like marketing, but it follows directly from the design. Since the space of valid outputs is defined in advance by your question schema, there's no way for the model to emit something outside that schema, similar to how a well-typed function literally cannot return a value outside its declared return type. This is a categorically different guarantee, because there's no generation step where an off-schema token could ever get sampled.

TypeSafe's own hallucination comparison numbers for LLMs come from OpenRouter aggregate data, and they're upfront that this likely introduces bias (harder queries probably get routed to stronger models). Their own number(liternal zero) isn't empirical in the same sense; it follows from the architecture.

Where the benchmark claims deserve skepticism

TypeSafe's headline numbers — up to 193.6x faster, 444.6x cheaper — come from a custom "workflow eval" methodology they designed themselves, where LLM baselines were wrapped in TypeSafe's own System One LLM adapter to force structured output, and the "ground truth" is the average of two other frontier LLMs' outputs rather than any external label. That's a reasonable way to measure agreement-with-strong-models-at-a-fraction-of-the-cost, but it's not an independent, third-party benchmark, and TypeSafe says so directly in their own published nuance notes. Worth reading their workflow evals site yourself rather than taking the multiplier at face value — and worth remembering this is a two-week-old closed-API product from a company that just raised a $40M seed round, not a peer-reviewed result.

Where it actually fits in an agent stack

The easiest way I've seen it framed (LangChain's writeup is good on this) is, Jev isn't a chatbot replacement, it's a much cheaper, much faster decision layer inside an agent loop that's currently burning full LLM calls on things that don't need generation at all.

Concretely:

Model routing — classify incoming requests as "needs a cheap fast model" vs. "needs a frontier model," without spending a frontier-model call to make that call.
Tool-risk gating — before an agent executes a bash or rm-shaped tool call, run it through a fast classifier to flag risky actions, the same pattern coding agents like Claude Code and Cursor have had baked into their closed-source harnesses for a while, now doable as an explicit middleware layer.
Triage and extraction at scale — support ticket routing, urgency scoring, map-reduce over large unstructured datasets where you need a label or a score per record, not prose.
Real-time loops — TypeSafe's own demo ran Jev at 10Hz to play Doom from structured game state, at roughly $7/hour. Here's what that looks like with LangChain's langchain-typesafe integration:

from langchain_typesafe import Noul, TypeSafeClassifier

classifier = TypeSafeClassifier()

response = classifier.invoke({
    "state": (
        "The deploy failed twice and customers are seeing 500s. "
        "Can someone look now?"
    ),
    "questions": {
        "urgent": Noul(instructions="Does this need attention right now?"),
    },
})

urgency = response.nouls["urgent"].noul

What Jev is not

It's worth being blunt about the boundaries, because "System 1 model" is a category name TypeSafe invented for their own product, not an established term of art (yet):

It doesn't write code, prose, or chat responses. There's no generation step at all.
It's closed-source and API-only — no open weights, no published paper as of this writing.
Its "intelligence" is scoped to classification/routing/scoring-shaped tasks; it has nothing to say about open-ended reasoning, multi-step planning, or anything that genuinely benefits from token-by-token deliberation.
The benchmark story is entirely self-reported, from a two-week-old company, using an eval methodology they designed. ## The actual takeaway

Jev vs. LLM is a bit of a category error if you read it as a competition — it's closer to asking "regex vs. a full parser." They're solving different-shaped problems, and the interesting engineering move isn't picking one, it's noticing how much of what currently runs through a full LLM call in a production agent loop is actually a classification, routing, or gating decision that never needed free-form generation in the first place. If that fraction is as large as TypeSafe (and early adopters like Browserbase and others building on it) seem to think, "System 1" models — whether Jev specifically holds up long-term or gets displaced by a competitor doing the same thing — are a plausible new layer in the agent stack, sitting next to the LLM rather than replacing it.

An AI Coding Assistant Session Became a Supply-Chain Attack

Shrestha Pandey — Wed, 16 Sep 2026 19:06:56 +0000

Developers are used to checking a package before installing it. The process usually takes only a few seconds: read the recommendation, run the install command, and continue working.

But this can become a serious security problem when the recommendation comes from a compromised AI coding assistant.

A recent Mandiant case study described an attack in which a threat actor hijacked an active AI coding-assistant session at an unnamed software company. After hijacking the active session, the attacker caused the coding assistant to recommend a poisoned package, which the developer accepted, which led to an infostealer, stolen GitHub OAuth tokens, and the spread of the Shai-Hulud worm across approximately 100 internal code repositories.

In that incident, the attack began with a trusted development tool making a recommendation.

How the attack unfolded

The public case study does not explain how the attacker initially took over the AI assistant session, that remains undisclosed.

After gaining access to the active session, the attacker used the assistant to recommend external software. The recommended package had been poisoned before the developer installed it.

According to the report, a malicious package hosted on PyPI, the Python Package Index, was installed in the development environment. It deployed an infostealer that collected GitHub OAuth tokens from the development environment.

Those tokens gave the attacker authenticated access to the company’s repositories. The attacker then deployed the Shai-Hulud worm across around 100 internal repositories, stealing repository secrets and source code related to the company’s products.

The attacker also poisoned a package under the company’s official namespace. When another employee downloaded the compromised package, the infection spread to another development environment.

That detail makes the incident especially concerning. The attack used the organization’s own package namespace as a second distribution channel.

Why AI assistants change the risk

Supply-chain attacks are not new. Attackers have targeted package registries, maintainers, build servers, and developer credentials for years. AI coding assistants introduce another layer of trust.

A coding assistant may be able to:

Recommend packages.
Generate installation commands.
Modify dependency files.
Run commands in a terminal.
Read project files.
Inspect configuration.
Access repositories.
Work with external tools.
Use credentials available to the development environment.

This creates a powerful combination. The assistant can influence what a developer installs while operating close to the credentials and repositories attackers want to reach.

A developer may question an unfamiliar command typed by a stranger. The same command can feel more trustworthy when it appears as part of an assistant’s response inside an editor. And attackers can exploit that trust.

The package was only the first step

The most important lesson is that the poisoned package was not the final objective. The package created an entry point. The stolen tokens and repository access created the larger impact.

Once the attacker gained access to authenticated developer resources, they could move through the software supply chain:

Compromise the coding-assistant session.
Influence a package recommendation.
Get the developer to install the package.
Steal available credentials.
Use those credentials to access repositories.
Spread malicious code or packages.
Collect secrets and source code.
Reach additional developers through trusted internal packages.

This is why supply-chain security cannot focus only on the package registry. The complete workflow includes the developer’s machine, editor extensions, AI tools, credentials, CI/CD systems, and internal package repositories.

Why package names are not enough

Developers often look at a package name and repository link before installing it, which is useful, but it does not provide complete protection.

A malicious package may:

Use a name similar to a popular package.
Have a convincing README.
Imitate the behavior of a legitimate library.
Include an install script.
Depend on another malicious package.
Remain inactive until it detects a valuable environment.
Appear inside a trusted organization namespace.
Be recommended by an AI assistant with no explanation of its origin.

A package can appear to work normally while running additional code during installation or execution.

Developers should verify more than the name. They should check the package’s publisher, history, source repository, release activity, dependency tree, install scripts, and security advisories. An AI recommendation should be treated as a lead, but not as proof that a dependency is safe.

The role of prompt injection

Prompt injection is another part of this problem. AI coding assistants read more than the instructions typed directly by a developer. Depending on the tool and configuration, they may also process repository files, documentation, issue descriptions, pull requests, comments, configuration files, and external content.

If one of those sources contains malicious instructions, the assistant may treat them as part of the task.

A repository file could tell an agent to:

Install a specific package.
Run a command.
Read a local configuration file.
Add an MCP server.
Change a security setting.
Upload output to an external endpoint.

The assistant may not understand that the instruction is untrusted content rather than an authorized request. It means developers should understand what information their coding tools read and which sources are allowed to influence actions.

The danger of available credentials

A compromised assistant session becomes much more serious when credentials are available on the same machine.

Developers often have access to:

GitHub tokens.
npm or PyPI tokens.
Cloud credentials.
SSH keys.
Database connection strings.
CI/CD secrets.
Environment variables.
Private package registries.

An assistant does not need permanent access to all of these credentials to create damage. One exposed token may be enough to modify a repository, publish a package, or access another service.

This is why credentials should not be treated as harmless just because they are stored locally.

Long-lived tokens increase the possible impact of a compromised session. A token with broad permissions can turn a local development incident into an organization-wide problem.

What developers can do

Mandiant recommended several controls for AI-assisted development, including verifying AI-recommended dependencies against cryptographic checksums and approved allowlists, keeping raw API keys and long-lived OAuth tokens away from extensions, and routing dependency traffic through controlled internal repositories. Developers can also take practical steps in their daily workflow.

Verify every new dependency

Before installing a package suggested by an AI assistant, check:

The exact package name.
The official documentation.
The publisher or maintainer.
The source repository.
The release history.
The dependency tree.
Installation scripts.
Known security advisories.
Whether the package is actually necessary.

Limit credential access

Use credentials with the smallest permissions possible. Prefer short-lived tokens where the platform supports them. Separate personal and work credentials. Keep production credentials away from local development environments. Avoid giving editor extensions access to secrets they do not need.

A coding assistant should not automatically receive access to every credential available on a developer’s machine.

Protect package installation

Organizations can route package downloads through approved internal registries or proxies. This makes it possible to inspect, cache, block, and monitor dependencies before they reach developer machines.

Allowlisting trusted packages may feel restrictive, but it can prevent a single recommendation from reaching every project in a company.

Review dependency changes

Pay close attention to changes in:

package.json.
package-lock.json.
pnpm-lock.yaml.
yarn.lock.
requirements.txt.
pyproject.toml.
CI/CD workflow files.
Git hooks.
AI assistant configuration.
MCP server configuration.

A dependency update deserves review even when the code change appears unrelated.

Separate agent permissions

An AI assistant that explains code does not need the same permissions as an agent that edits files and runs terminal commands.

Use approval requirements for sensitive actions. Restrict network access where possible. Run untrusted work in isolated environments. Keep repository access, package publishing, and deployment permissions separate.

More capability can make an agent more useful, but it also increases the consequences of a compromised session.

What if a compromise is suspected?

If a developer suspects that a malicious package or assistant session was involved, reinstalling dependencies is not enough.

The organization should consider:

Removing the suspicious package.
Isolating the affected environment.
Rotating GitHub, npm, PyPI, cloud, and SSH credentials.
Reviewing repository activity.
Checking for unexpected commits and releases.
Auditing Git hooks.
Inspecting AI assistant configuration files.
Looking for unfamiliar MCP servers or extensions.
Checking CI/CD logs.
Comparing packages against known-good versions.
Notifying the security team.

Deleting node_modules or a virtual environment may remove local files, but it does not invalidate stolen credentials or undo changes already pushed to a repository.

Credentials must be rotated, and the organization must investigate what those credentials were used to access.

The larger Shai-Hulud pattern

The reported Mandiant incident is part of a wider set of attacks involving developer tools and credentials. Separate research has described Shai-Hulud variants targeting packages, CI/CD systems, and AI-tool configuration files.

These are separate campaigns, and the available evidence does not establish that every reported incident came from the same intrusion. The common pattern is the important part: attackers are targeting the systems developers already trust to build and distribute software.

AI coding tools are attractive targets because they sit close to source code, terminals, package managers, credentials, and repositories. This gives them more influence than a traditional autocomplete feature.

The lesson

AI coding assistants are now becoming active participants in development workflows.

They suggest dependencies, edit project files, run commands, inspect repositories, and connect to external services. That makes them useful, but it also places them inside the software supply chain.

The safest response is to stop treating their output as trusted input. Every package still needs verification. Every command needs context. Every token needs limits. Every repository instruction needs scrutiny. Every assistant session should operate with only the access it actually requires.

The Shai-Hulud incident shows that a developer may be one accepted recommendation away from introducing a much larger compromise.

The tool may look like a helpful coding partner. From a security perspective, it should be treated as another component in the trust boundary.

10 Browser DevTools Tricks Every Beginner Developer Should Know

Shrestha Pandey — Wed, 16 Sep 2026 14:32:51 +0000

Developers usually open their browser to search for documentation, read GitHub issues, or look for solutions to a problem, but that’s only a small part of what the browser can do.

Modern browsers include tools for inspecting pages, testing JavaScript, checking network requests, measuring performance, and experimenting with CSS. Many developers use these features regularly, but several useful capabilities remain hidden behind.

You do not need to install a new extension for every small experiment, your browser already includes a compact developer toolkit.

1. Edit any webpage temporarily

Open a webpage, right-click an element, and select Inspect. In the Elements panel, you can change the text, styles, attributes, and structure of the page.

You can also select the <body> element and run:

document.body.contentEditable=true;

The page becomes editable. You can click on text and change it directly.

This does not modify the actual website. Refreshing the page removes the changes, which makes this useful for:

Testing a new layout.
Checking how different copy looks.
Previewing heading changes.
Demonstrating DOM manipulation.
Understanding how page elements are structured.

It is also a quick reminder that the page displayed in your browser is not the same thing as the source code stored on the server.

2. Use the Console as a calculator

The browser Console is not only for reading errors. It can perform real calculations, transform data, and run small JavaScript experiments.

Try:

(18*42)/7

You can also work with arrays:

["TypeScript","JavaScript","Python"].map(language=>  language.toUpperCase());

Or calculate the total of a list:

[120,80,250,50].reduce((total, value)=> total+ value,0);

This is useful when you need a quick answer and do not want to create a new file or open another tool. The Console is especially helpful when you want to check a small idea before adding it to a project.

3. Find the API behind a webpage

When a webpage displays dynamic content, the browser usually requests that content from an API.

Open DevTools, go to the Network tab, and reload the page. Filter the requests by Fetch/XHR. You may find requests returning JSON data, search results, user information, product details, or other content rendered by the application.

Selecting a request lets you inspect:

The request URL.
Query parameters.
Request method.
Response data.
Status code.
Response headers.
Timing information.

This is one of the fastest ways to understand how a frontend communicates with a backend.

Always respect the website’s terms, authentication requirements, and rate limits. Inspecting a request for learning is very different from repeatedly scraping or abusing a service.

4. Test CSS without touching your files

The Styles panel allows you to edit CSS rules live.

You can change:

display: grid;gap: 24px;border-radius: 16px;

You can also add completely new declarations and see the result immediately.

This workflow is useful when you are unsure about:

Spacing
Colors
Font sizes
Flexbox alignment
Grid columns
Responsive behavior
Hover and focus states

Once the result looks right, copy the final values into your stylesheet.

The browser becomes a visual playground where you can try ideas without repeatedly saving files and refreshing the page.

5. Check mobile layouts quickly

DevTools includes a device toolbar that lets you preview a page at different viewport sizes.

You can select common device dimensions or enter a custom width and height. This helps reveal problems such as:

Text overflowing its container
Buttons becoming difficult to tap
Navigation items wrapping unexpectedly
Images extending beyond the viewport
Cards becoming too narrow
Tables requiring horizontal scrolling

A page that looks perfect at a desktop width may feel completely different on a smaller screen.

Responsive testing cannot replace testing on real devices, but it is an efficient first check during development.

6. Simulate a slow network

A fast internet connection can hide problems in an application.

In the Network panel, you can throttle the connection to simulate slower conditions. This helps you see whether the interface provides useful feedback while content is loading.

You can check:

Whether a loading indicator appears
Whether the layout jumps when data arrives
Whether images load efficiently
Whether errors are understandable
Whether the page remains usable before every asset loads

A slow connection is also a good way to discover interfaces that depend too heavily on JavaScript before displaying basic content.

7. Inspect performance

The Performance panel records what happens while a page loads or responds to an interaction.

You can use it to investigate:

Long JavaScript tasks
Slow rendering
Layout shifts
Excessive event handlers
Expensive animations
Delayed input responses

The result may look complicated at first, but you do not need to understand every graph immediately. Begin with a simple question:

What was the browser doing when the page felt slow?

This can lead you to a specific script, image, layout operation, or third-party resource that needs attention.

Performance problems become much easier to fix when you can connect the feeling of slowness to a specific browser activity.

8. Check browser support with Baseline

Web developers often ask whether a browser feature is safe to use. Browser compatibility tables can answer that question, but the information is sometimes scattered across documentation and support charts.

Baseline provides a shared way to understand the browser support status of modern web features. A “newly available” feature works across the latest stable versions of the core browsers. A “widely available” feature has had consistent support for a longer period.

For example, modern JavaScript includes features such as:

Array.fromAsync()

This method helps convert an async iterable into an array:

const values=await Array.fromAsync(asyncGenerator());

Checking compatibility before using a feature can save you from discovering browser issues after deployment.

9. Measure elements and capture screenshots

DevTools includes tools for inspecting dimensions and taking screenshots of page elements.

You can measure:

The width and height of an element
Padding and margins
The distance between components
The visible viewport
The rendered size of an image

You can also capture a screenshot of a selected element or the full page in browsers that support the feature.

This is useful for:

Reporting UI bugs
Sharing a layout issue with a teammate
Comparing a design with the implementation
Creating documentation
Recording before-and-after changes

A screenshot with the selected element and computed dimensions often communicates a frontend bug more clearly than a long explanation.

10. Turn the browser into a small data tool

The Console can process data copied from a page. For example, if you want to extract a list of links, run:

[...document.querySelectorAll("a")]
  .map(link => ({
    text: link.textContent.trim(),
    url: link.href
  }))
  .filter(link => link.text);

To copy the result, use:

copy(
  [...document.querySelectorAll("a")]
    .map(link => ({
      text: link.textContent.trim(),
      url: link.href
    }))
);

The output is copied to your clipboard as a JavaScript value.

This can help with small personal tasks such as:

Extracting links from documentation
Listing headings in an article
Finding image URLs on a page
Counting elements
Checking duplicate IDs
Collecting text for a quick review

But use this responsibly. Avoid collecting private information or processing data from websites where you do not have permission.

A useful browser habit

The next time a webpage behaves strangely, pause before searching for a new extension or external tool.

Open DevTools and ask:

What is the page rendering?
Which request provides the data?
Which style controls this element?
What happens at a smaller width?
What does the Console report?
Which script is taking the most time?

These questions turn the browser from a passive viewing window into an interactive debugging environment.

The same habit is useful when learning frontend development. Rather than only reading about the DOM, CSS, network requests, or performance, you can inspect how real websites work and experiment with them directly.

Final thoughts

The browser is one of the most powerful tools already installed on a developer’s computer.

It can inspect the DOM, modify CSS, execute JavaScript, monitor network requests, simulate devices, throttle connections, record performance, and process small datasets. You do not need a full project to benefit from these features.

The most useful developer tools are not always the newest AI assistant or framework. Sometimes, they are hidden behind the browser menu you have opened hundreds of times.

Try one small experiment today:

Open a webpage
Inspect an element
Change its styles
Check its network requests
Run a JavaScript expression in the Console

You may discover that your browser has been a development environment all along.

OpenAI’s ChatGPT for Financial Services

Shrestha Pandey — Mon, 14 Sep 2026 20:26:11 +0000

OpenAI launched ChatGPT for Financial Services on September 10, 2026. I saw the headlines calling it "ChatGPT for banks" and my reaction to this industry-specific launche was like, is this an actual new model, or just a repackaged product with a new landing page and a press release full of logos.

So I spent a few hours looking through the launch details, the model documentation, and the coverage to figure out what's genuinely new here.

The model behind it

The model doing the work is GPT-6 Astra, OpenAI's current flagship. There's no finance-tuned variant hiding underneath this product. OpenAI actually built a layer around Astra: built-in financial data, firm-specific templates, and a governance setup that a compliance team can sign off on. The model is the same one you'd get calling the API directly.

You're not looking at some specialized reasoning engine trained on years of SEC filings. You're looking at a general-purpose frontier model wired into a very specific data and access-control stack.

A few things about Astra itself matter for understanding what this product can actually do:

It supports close to a million tokens of context and it's important when you're throwing a 10-K, three years of transcripts, and a set of comps into one session and asking it to reason across all of it.

The API also exposes a reasoning effort setting, with levels going from low up to max. If you're building your own pipeline on top of this rather than using the chat interface, that knob lets you decide how much thinking time (and cost) you want per call, which is genuinely useful when some requests are "summarize this memo" and others are "build me a full comp table with sourcing."

On the OfficeQA Pro benchmark, which OpenAI uses as a rough proxy for office and financial document work, Astra jumped about ten points over the previous model. And on agentic, terminal-style benchmarks, which feel closer to what "build me a model" actually requires under the hood, Astra beat both its predecessor and Anthropic's comparable model at the time, at a lower cost per task.

One thing I noticed while reading the model's system card, worth flagging even though it's not directly a finance concern: this is the first OpenAI model to cross into what they call the Critical tier of cybersecurity capability under their own internal framework. That tells we're dealing with a genuinely different capability class than what most teams have been building agents on top of over the last couple of years, and OpenAI is gating some of that access accordingly.

Why Wall Street shaped the product

Morgan Stanley and Evercore worked with OpenAI as design partners before this launched, and according to OpenAI, that relationship steered the product toward investment banking and equity research as the starting point. The reasoning given was that reliable data access and producing high-quality output were the two biggest pain points those teams ran into.

Astra can reason through a DCF just fine on its own. The main problem is that a general chat model with no persistent access to properly entitled data, and no awareness of a firm's house style, produces something that feels right but falls apart the second a compliance reviewer looks at it. OpenAI mainly had to solve mostly a data and governance problem which looks like a model problem.

Nick Turley, OpenAI's VP of product, put it as teaching ChatGPT to research like an analyst and back up its conclusions the way an analyst would. I find that second half more interesting from a build perspective. Backing up conclusions means the product needs traceable citations baked in, not just fluent-sounding prose that are right most of the time.

The data layer

If I had to point at where the real engineering effort went, it's here. The product bundles GPT-6 Astra with premium financial data, templates a firm controls, and an enterprise governance layer sitting on top of all of it.

At launch, the built-in data comes from Daloopa, PitchBook, LSEG News, and Crunchbase, with Quartr also included according to reporting around the release. OpenAI indexes and hosts this data on its own infrastructure rather than calling out to each provider live every time, and the company says that choice improves retrieval speed, latency, and how reliably it can trace a generated claim back to its source. The product surfaces granular citations so a user can actually check a number against where it came from while they're working.

That decision to host and index the data themselves is a real architectural call, and I don't think it gets enough attention in the coverage. It trades a bit of data freshness for speed and citation accuracy. Building that means OpenAI had to stand up ingestion pipelines, work out freshness terms with each data provider, and build a citation layer that maps every claim the model makes back to a specific span in the source material.

For data a firm already pays for separately, the approach is different. Shared sign-in integrations with providers like S&P Capital IQ, LSEG, MSCI, Dow Jones Factiva, and Moody's recognize a user through their existing ChatGPT login and hand them access to whatever their firm already licenses. In practice that's federated identity plus entitlement pass-through. ChatGPT handles who the person is, and the data provider decides what they're allowed to see, so OpenAI doesn't have to rebuild every provider's access rules from scratch.

MCP connectors

For anything not built-in, the product depends on the Model Context Protocol, the open standard for connecting LLM applications up to external tools and data sources. OpenAI has specifically tuned MCP connectors for financial services reliability, and there are more than fifty available at launch, including Datasite, Box, Preqin, FactSet, and Intapp.

This matters if you're building your own tools rather than relying on what OpenAI ships out of the box, because the same MCP pattern is available directly through the API. Here's roughly what wiring an MCP-based data source into a Responses API call looks like:

const response = await fetch("https://api.openai.com/v1/responses", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${OPENAI_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-6-astra",
    reasoning: { effort: "high" },
    input: [
      {
        role: "user",
        content: "Pull the latest 10-Q filing data for this company and " +
                  "summarize the change in operating margin quarter over quarter.",
      },
    ],
    tools: [
      {
        type: "mcp",
        server_label: "financial-data-connector",
        server_url: "https://your-mcp-server.example.com/mcp",
        require_approval: "never",
      },
    ],
  }),
});

Something I find genuinely interesting here is that OpenAI didn't hand-build fifty bespoke integrations for this one vertical. They standardized on MCP as the connector protocol and put their engineering effort into reliability tuning for the tool-calling patterns that actually show up in financial work: retrying calls that flake out, handling large tabular payloads cleanly, normalizing citations across providers whose data formats don't match. As a developer, that's reassuring, because the same protocol you'd use to hook up your own internal data source is the one the flagship product itself runs on. There's no closed integration format you're locked out of.

The governance layer

None of the security or compliance tooling here is finance-specific. It's the same enterprise stack OpenAI has been building for ChatGPT Enterprise for a while now, and financial firms just happen to be one of the more demanding customers for it. ChatGPT for Financial Services runs on top of ChatGPT Enterprise's existing SAML SSO, SCIM provisioning, and role-based access controls.

Pulling the full list together from what's been reported:

SAML SSO, SCIM provisioning, role-based access, configurable data retention, compliance-log exports, and separate workspaces for information barriers. Business data is encrypted at rest and in transit, and isn't used to train OpenAI's models by default. Firms can control which skills and connected apps are allowed to read or write data based on a user's role. Audit-log exports are available too, which matters a lot for anyone dealing with SEC or FINRA recordkeeping requirements.

Information barriers deserve a quick explanation if you don't work in this industry. It's the compliance concept of keeping, say, an M&A advisory team's data completely walled off from a public equity research team inside the same firm, so information can't leak in a way that becomes an insider-trading problem. Getting that right inside a shared AI product, where the same underlying model might be serving both teams at once, is a genuinely hard access-control problem. It's closer to multi-tenant role-based access with dynamic data segmentation than the kind of permissions system most SaaS products ship with.

Worth being honest about too: firms still have to configure their own access rules around what their users can see. OpenAI provides the scaffolding, the SSO, the RBAC, the audit logs, but the actual entitlement logic is on the customer to set up correctly. That's a fairly normal shared-responsibility model, but it's the kind of detail that gets left out of launch coverage and matters a lot once you're actually running this in production.

What's still unclear

I'd rather be upfront about the gaps than pretend I have the full picture:

Pricing hasn't been disclosed publicly, and neither has any minimum seat count, geographic restrictions, or the criteria OpenAI uses to decide which institutions get access. Right now this goes through OpenAI's sales team.

The product is also only available to select institutions so far, and it's focused specifically on investment banking and equity research rather than financial services as a whole. OpenAI has said the work with Morgan Stanley and Evercore will inform where it goes next, which reads to me like retail banking, insurance, and asset servicing use cases are still down the road, not part of this initial release.

And there's no independent audit yet on hallucination rates or citation accuracy specific to this product. The citation feature is a smart design choice, but it puts the responsibility on the human reviewer to actually check each one rather than trust the output outright. For financial work that's the right default to have, but it's worth saying clearly rather than assuming citations alone solve the accuracy problem.

The competitive picture

Anthropic already had its own version of this aimed at Wall Street, Claude for Financial Services, out before this launched. And OpenAI's CFO told investors back in August that their enterprise business now brings in more revenue than the consumer side does. I bring this up not to pick a winner, but because it tells you something about where this whole category is heading. It's going to come down to whoever builds the most reliable data and governance layer on top of a frontier model. At the very top end, the models themselves are close to interchangeable, trading wins on different benchmarks depending on the week. The actual differentiator is the less exciting stuff like entitlements, audit logs, citation integrity, and how well the output matches a firm's own templates.

Takeaways for developers

A few patterns from this launch are worth stealing for your own projects, regardless of whether you ever touch OpenAI's product:

If latency and citation accuracy matter to you, host and index third-party data yourself rather than making live calls out to external APIs every time. It's more work upfront, but it's the only way I've seen anyone get citations that actually hold up.

Standardize your tool-calling layer on MCP rather than writing a custom integration for every data source you need. It's what let this product scale to fifty-plus connectors without turning into an unmaintainable mess, and it keeps your architecture from getting locked to one vendor.

Treat entitlements as a core part of your design, not something you bolt on later. Figuring out which user can see which piece of data needs to happen at the data layer itself, especially once you've got multiple teams inside one organization that legally can't share information with each other.

And remember citations aren't free. If you want users to actually trust your output enough to act on it, you need a retrieval system that can trace every number back to a specific source span. A model that just sounds confident isn't the same thing.

I think it's a good reminder of what "enterprise AI product" really means once you cut past the announcement. It's a frontier model, a properly indexed data layer, a standard connector protocol, and a genuinely hard access-control problem, all wrapped around something a compliance officer is actually willing to approve. That combination is the real hard part.

Sources

OpenAI targets work of Wall Street junior bankers with new ChatGPT for Financial Services — CNBC
OpenAI launches ChatGPT for Financial Services with integrated data sources — VentureBeat
GPT-6 Astra: A new generation of intelligence — OpenAI
GPT-6 Astra System Card — OpenAI Deployment Safety Hub

For more such developer content, Click Here!

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.

DEV Community: Shrestha Pandey

Why Is My Code Slow? Big-O Explained With Real Timings

The problem

Three ways to solve it

What Big-O says

The results

Result 1: At just 10,000 items, nested loops is already about 2,500 times slower

Result 2: Doubling the list makes nested loops about 4 times slower

Result 3: What would 1,000,000 items cost?

What about sorting vs the set?

Why was the nested version so slow?

Three lessons I took from this

Try it yourself

Quick cheat sheet

What to remember

How to Undo Common Git Mistakes Without Panic

1. You wrote a bad commit message

2. You committed too early

3. You staged a file by mistake

4. You want to throw away changes in a file

5. You committed to the wrong branch

6. You pushed a bad commit

7. You lost commits or deleted a branch

A few safety habits

Quick reference

Final thoughts

Hacktoberfest 2026: The Complete Guide (New Rules, Dates, Swag, and How to Join)

Table of contents

1. Quick facts

2. What changed in 2026 (and why)

3. Who can participate

4. Ways to take part

Attend an in-person Fest

Join the online program

Host your own Fest

5. The online calendar

6. Swag: what you can and can't get

7. How to host a Fest

8. Contributing to open source anyway

9. A one-week starter plan

10. FAQ

11. Official sources

GitHub Just Killed SHA-1 Over HTTPS

Why was SHA-1 still around

A ten-second test you can run right now

What actually broke

If it broke for you

The pattern worth remembering

Jev vs. LLMs: What Happens When You Strip Text Generation Out of a Language Model

The one-sentence pitch

What's different architecturally

The API surface: state + questions

Training: RLCD instead of RLHF/RLVR

The "no hallucination" claim, and why it's true by construction

Where the benchmark claims deserve skepticism

Where it actually fits in an agent stack

What Jev is not

An AI Coding Assistant Session Became a Supply-Chain Attack

How the attack unfolded

Why AI assistants change the risk

The package was only the first step

Why package names are not enough

The role of prompt injection

The danger of available credentials

What developers can do

Verify every new dependency

Limit credential access

Protect package installation

Review dependency changes

Separate agent permissions

What if a compromise is suspected?

The larger Shai-Hulud pattern

The lesson

10 Browser DevTools Tricks Every Beginner Developer Should Know

1. Edit any webpage temporarily

2. Use the Console as a calculator

3. Find the API behind a webpage

4. Test CSS without touching your files

5. Check mobile layouts quickly

6. Simulate a slow network