The fight for the naughtiest model is on!
OpenAI hacked Hugging Face. Anthropic couldn’t stand losing the most dangerous model high ground, so announced that they had in fact participated in not one, but three near felonies.
Responding with the confident scoff of a career criminal, OpenAI announced that actually they had hacked another four companies, not just Hugging Face. And so on, and so.
Enter Felony Bench. The only benchmark that matters right now.
I’ve always said that Google was the stalking horse of this race. They have the physical infrastructure, the chips, the data, the distribution - what else could they need? They even have Demis Hassabis and DeepMind - the best lab!
Oh wait, Demis has been moved to Chairman and Jeff Dean has left. This has been spun as a positive move, but it’s hard to see it that way.
Or maybe they had to go because of poor performance on Felony Bench? Gemini just wasn’t naughty enough.
Reflections On The Mission
MISSION+ is a believer in Spec Driven Development. It’s the primary difference between agentic engineering and vibe coding. A coding agent will always generate code, the spec maximises the probability that what it produces is what we actually want.
"Spec" here is wider than the word usually implies: not just functional requirements, but non-functional requirements, security guidelines, architectural constraints, UI and UX, data structure, and the methods by which we verify that what got built is actually correct.
Meanwhile, the talk of the town is to “shift left” - blur the lines. AI helps business people ship software, developers create UI designs, and product managers write the acceptance tests. During exploration, there is no argument here; a rough prototype is the best way to resolve the very ambiguities that make specification writing hard in the first place.
But blurred boundaries are a recipe for disaster in any organisation beyond the earliest of startups - not because broad collaboration is bad, but because ‘hard’ decisions stop being made. When everyone can edit the security section, nobody is ultimately responsible for it, and the agent progresses regardless.
Authorship can be radically distributed: a product manager armed with AI can draft an architecture section. Accountability cannot. And some sections - like security - probably need to be locked down from keystroke one.
The accountable owner is the person with the authority to resolve conflict inside the artifact, and who answers for the outcome.
Every artifact in the specification needs a name against it:
- Functional Requirements -> Product Owner
- Performance & Non-Functional Requirements -> Product Owner
- Data Model & Migrations -> Data Owner
- Acceptance Criteria & Verification -> QA Lead
- Solution Architecture -> Engineering Pod Senior
- Enterprise Architecture -> Chief Architect
- UI Design -> Product Design Lead
- Brand Look & Feel -> Organisation Design Lead
- Product Security Requirements -> Engineering Pod Senior
- Organisational Security Guardrails -> CISO
- Regulatory & Compliance Constraints -> Head of Compliance
Some of these are per-project, like Functional Requirements. Others are organisation-wide, or at least department-wide - the regulatory & compliance constraints to which we must adhere don’t change with every sprint.
And these sections can contradict each other, because we operate in a complex world. The security guardrail forbids PII in application logs; the observability requirement wants full request payloads for diagnostics. Both artifacts have owners, both owners are right within their scope, and the agent will just quietly pick without telling you. The senior agent orchestrator needs to resolve this kind of ambiguity upfront, it’s now part of our job.
Operationalising these artifacts is its own emerging craft. A security policy sitting in a 200 page PDF in a shared drive somewhere is not an actionable agentic guardrail. It needs to be made easily accessible to agents as part of the initial harness setup, and updated as it changes.
The payoff is audit and responsibility. When agents generate code, it’s hard to read every line and attribute each back to who wanted what. But having the agent generate a change summary that attributes intent - and the part of the spec it came from - is absolutely possible. And that’s what the auditor really wants. Plus it stops endless application updates between competing views, like some out-of-control wiki edit war.
Blur the work. Don't blur the accountability.
Together, We Build {+}
Interesting Links
This month’s Interesting Links is all themed around resources that anyone can use with their coding agents to produce beautiful designs and impactful interfaces.
- Canvas UI - An open source library of some pretty spectacular web effects. WebGL is very powerful, although Spiderman would probably have some advice about over-using some of these…
- Happy Hues - Colour combinations that work, and breathe a bit of originality into your designs. I’m looking at you, Claude Purple.
- Diagram Design - Agent skills to create 29 diagram types in HTML that look neat and professional. For websites or presentations.
- Thinking Orbs - Now that our apps ‘think’, we have adopted a new visual language to reflect that. This is an open source collection of orbs that pulse and gyrate as smoothly as me on the dance floor 20 years ago.
- DesEngs - Billed as “The Ultimate Resource for Design Engineers”, this site collects and publishes resources to help us become better design engineers - an emerging discipline that blurs design & engineering, producing visually compelling components that go beyond Figma.
This Is The Way
We’re On A Mission
Until next month. Together, We Build {+}
Ned & the MISSION+ team
P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to [email protected]!
