founder @nuanced_dev prev 7 yrs @github, @uwaterloo writing about AI, code, and how humans actually understand software
rent free in your head
Joined August 2009
- Tweets6K
- Following1.7K
- Followers6.7K
- Likes32.9K
Pinned Tweet
we made a document editor for building software with agents
write a spec. get comments from an agent that has read your codebase. work through the decisions, then have it build.
Introducing Nuanced Canvas.
there’s a HUGE difference between having an idea and being able to articulate it.
i’ve sometimes felt slow as an engineer, but i’ve come to realize that the friction I felt was developing my product+eng intuition. struggling with complexity forced me to interrogate the abstractions/ux that sustained it and to distinguish necessary complexity from unnecessary friction. this helped me develop a sharper sense of where real problems lie.
writing is a big part of that discipline. it forces you to turn vague intuitions into explicit reasoning and exposes the gaps in your understanding. the difficulty of articulating an idea is often evidence that you haven’t fully understood it yet. it’s the process of connecting your felt intuition to something tangible.
when code was expensive to write, the act of writing it forced you to have confront your assumptions beforehand.
now it’s easy to go from a vague idea to implementation without ever developing a clear opinion. but the cost of that is (1)premature commitment to an idea you haven't evaluated (2) the false sense of confidence created by working code.
some of the friction we removed was doing useful cognitive work.
this is why I’m building nuanced.dev
it gives you a place to thoughtfully examine your assumptions and develop your ideas clearly
writing forces you to wrestle with an idea
sometimes you don’t really know what you think until you try to write it down
when you don’t write down your reasoning, the decisions still get made for you. you just lose your ability to question them later.
the work to think through why something matters will always be useful.
nothing prepares you for loving someone this much. the joy is almost unbearable, and so is the vulnerability. your whole world becomes a little person who has no idea how completely they hold your heart
this is exactly why we built Nuanced Canvas nuanced.dev
agents produce code at a rate that quickly outpaces human understanding, but figuring out what to build, thinking through tradeoffs, and maintaining a clear mental model of our software are still hard.
we need better tools for thinking, not just faster tools for executing.
If AI makes you 10x faster at coding, why is your team not shipping 10x faster? Amdahl's law has the answer...
The law says the overall speedup is capped by the part you did not speed up. With `p` as the fraction of the work you accelerate and `s` as the speedup on that fraction, speedup is computed as attached.
Now plug in some numbers. Say writing code is 30% of the time from idea to production, and AI makes that part 10x faster. The overall speedup is 1 / (0.7 + 0.03), which is about 1.37x. Even if coding is half of the cycle, you get about 1.8x.
These numbers are illustrative, so use your own, but the shape stays the same. The rest of the cycle is still there:
- Figuring out what to build
- Aligning product, design, and other teams.
- Code reviews, which are now more than ever
- CI and CD takes the same wall time as before.
- Debugging and incidents, where code that nobody on the team wrote line by line takes longer to understand.
In fact, it can get worse than Amdahl predicts.
Faster code generation increases the load on every stage after it, so the review queue grows and the bottleneck shifts. A team that writes 10x more code with the same review capacity is just building a bigger queue, unfortunately
So if you want the team to actually ship faster, measure the whole path from idea to production and find where work waits. Then apply AI there too: review, test generation, flaky test triage, deploy safety checks. Otherwise, you have optimized the part of the system that was never the constraint.
Speeding up the typing was always the easy part :)
ayman nadeem retweeted
The trajectory is clear
New on our Frontier Red Team blog: using Claude to formally verify software at large scale.
Formal verification can prove that code is free of certain bugs, but historically it has only been feasible for small codebases (or required a lot of expert time).
With AI models, however, this is beginning to change. In collaboration with @theoremlabs, we used Claude to prove security properties in over one hundred real-world open-source libraries over the span of a few weeks.
Read our research in full here: anthropic.com/research/forma…
ayman nadeem retweeted
today in trying to be more ambitious: i asked for 100 ms startup time on our electron app. it did not go how i'd hoped
we're building a markdown editor for building software with agents @nuanced_dev. i'm a big fan of @zeddotdev and have always wanted to build an app that starts as fast as possible. i close and open apps many times a day, i prefer to quit an app i'm not using to protect my mental context
so upon reading @felixrieseberg's post last night, i went about actually being more ambitious with startup speed. it already starts fast, i'd previously profiled it to around 420 ms which feels solid. Opus 5.5 said that was probably the limit without going native.
but felix said to be unreasonable
so i was unreasonable. i asked for 100 ms.
and let me tell you, not all software is free. not even close. eking out performance gains is not something you can hill climb in a night. Fable 5.1 did manage to get it from about 420 ms -> 320 ms with a modified electron
the funniest direction Fable took was a hybrid where a native window starts fast and gets replaced with electron soon after. it technically hit 158 ms, but you're looking at the wrong ui for most of it. i checked the demo video and it looked insane, the native ui didn't match the electron ui and you just see a flash of it before electron takes over
the only way to get lower is going native or compiling typescript directly to a binary. i'm excited about scriptc but it's early and nowhere near able to compile a monster like electron. felix is a maintainer on electron so he may have thoughts
the models can crank away but there's a limit without better libraries. we need everything to be faster! we need electron -> binary compilation, maybe @jarredsumner will ship that with @bunjavascript but it sure won't happen with one agent cranking away in a night
next experiment is stripping electron down even further, will report back!
i think what’s tough about codex right now is the mental overhead of relearning where everything is. everything is compressed into chat, but the buttons keep moving.
i was making gifs for the prod launch, and sometimes there’s a download link, sometimes i have to locate the file in finder, sometimes i have to ask for it. same thing i’m trying to accomplish, different ways to get there. even how to interact with a preview isn’t consistent.
i get that dynamic interfaces sound cool in theory, but chat is a difficult form factor for this. discovery has to be really intuitive, because otherwise i’m figuring out how to use the tool all over again while trying to finish something.
5. The document is alive.
Specs often become outdated as the software changes. In Canvas, I can return to the same document to revisit a decision and edit the section I want to change.
The document is an ongoing interface to the software.
Nuanced Canvas helps you read and write about your software, and then the agent implements your changes in an isolated Git worktree. You review the diff and ship a PR.
Available for Mac.
nuanced.dev/
We built Canvas around five ideas:
1. I need to understand my software.
Sometimes I’m still figuring out what I want, and the agent hands me a complete plan that has me reviewing its conclusions before I’ve formed my own. Writing helps me work through those decisions myself before the agent steps in.
Try it: nuanced.dev
At GitHub, I loved writing specs and working through teammates’ comments before coding. I wanted to bring that experience to building with agents.