aymandfire

This is pretty much exactly the flow we built Nuanced.dev around.

Thank you! Baby was born in July, but we are actually back in the ER right now because she’s struggling :(

Propelcode looks awesome! So cool to see different people and perspectives shaping this space.

oh interesting! I haven’t used vscode for anything meaningful since shortly after leaving GitHub (2023). I generally find it overwhelming but codex added the annotations too and I love it.

hi I’m the author of the post. I think that’s basically the distinction I’m trying to make.

Historically, plan mode served two different roles:

1. making the agent’s instructions precise enough to execute 2. helping the human understand what was about to happen

I think #1 is less necessary as agents get better. #2 is going the other direction, it becomes more important as the model is able to do more on its own because larger chunks of work are happening with increasing complexity.

Where I’ve changed my mind is the interface for #2. I increasingly think an interactive, iterative workflow is closer to how people actually build understanding than being handed a long generated document, especially one they didn’t author themselves.

The human-understanding problem is very real though

I see what you’re saying. That’s actually why I built Nuanced (https://www.nuanced.dev), I wanted a better way for humans and agents to work through intent before the code got written.

but I think I overfit the interface to how I used to work without agents. when I was at GitHub, I wrote a lot of ADRs, RFCs, and design docs, and I liked that because writing is how I clarify my own thinking. with agents though, I’m often not doing the writing myself. I give the model a rough intent and it fills in a bunch of gaps, and then I get back a long, polished plan containing decisions I didn’t explicitly make.

That’s the part that feels broken to me. The plan can be detailed and technically correct, but still be hard to review because the important bits are buried and feel distant from my own thinking. All the assumptions and tradeoffs and questions may or may not be legitimate, but it’s hard for me to get into flow state and carefully check them.

So I still want the collaboration step. I’m just less convinced that generated prose à la plan mode is the right interface for it.

Thanks! If you ever wanna trade notes or if we can be of any help, feel free to reach out at [email protected]!

Hey, happy to chat about timeline estimates if you wanna shoot me an email at [email protected]

Hey! Coming soon. We're also working on a swe-bench test: https://github.com/nuanced-dev/nuanced/issues/10

In the interim, this is a test I did with Sonnet 3.5 + Cursor, showing how it impacted explanations (not solutions): https://github.com/nuanced-dev/nuanced/issues/31

Hi there! Like I said in the post, we're actively developing support for JS/TS next, and are building toward a language-extensible project. We started with an open-source Python tool. :)

Totally agree, working on publishing that soon! We're also working on a swe-bench test: https://github.com/nuanced-dev/nuanced/issues/10

In the interim, this is a test I did with Sonnet 3.5 + Cursor, showing how it impacted explanations: https://github.com/nuanced-dev/nuanced/issues/31

Will share results soon.

Yeah! We actually did an experiment where we provided AI tools with memory profiler outputs, Sentry exception reports, and telemetry from Datadog.

When debugging code, experienced developers don't read every file—they follow execution paths and understand system architecture. But today's AI coding tools try to read all files and get bogged down in unnecessary details.

With context windows limited to 200K tokens, cramming in random files isn't just inefficient, it's impossible for large codebases. If you’re debugging a failing test, you only need to understand the relevant files in the call chain. It's not about more context, it's about relevant context. That's what Nuanced provides through static analysis and machine learning.

At Nuanced, we're building tools that make AI-generated code more reliable.

As AI writes more code, we need better tools to trust it and technologies that ensure our human understanding keeps pace with this rapid development.

While everyone else races to ship new features with AI, we're focused on addressing gaps in AI coding tools and ensuring those features are reliable and maintainable rather than code that works today but becomes a liability tomorrow.

We're starting with an AI-powered Python language server that makes AI-generated code more reliable by understanding your entire system—using a deeper semantic understanding of code than LLMs have today, but also artifacts outside of code such as commit histories, configs, and team patterns.

We're a team of ex-GitHub engineers and researchers who've scaled some of the world's largest developer platforms. I'm Ayman (https://www.aymannadeem.com/about/), and before founding Nuanced, I spent seven years at GitHub where I helped build Semantic(https://github.com/github/semantic), an open-source library for parsing and analyzing code across languages—and scaled security systems to detect anomalous code patterns across millions of repositories. Our team’s deep experience in static analysis and large-scale system design shapes our approach to the AI reliability challenge today.

We've all been on-call at 2 AM, untangling complex service dependencies, and more recently, we've seen firsthand how AI accelerates development—both the wins and the wounds.

If you're building an AI coding tool and any of this sounds interesting to you—we should talk!

Read more at https://nuanced.dev/blog/the-reliability-gap