Paul Ardeleanu
Principal Architect at Vonage, part of Ericsson
London, United Kingdom
Actions
Paul is a Principal Architect at Vonage, working at the intersection of architecture, AI, and developer tooling, helping transform how developers interact with CPaaS and Network APIs. Having transitioned from managing Developer Relations teams to the central Architecture Team, he brings a unique perspective: understanding both the strategic vision required for enterprise architecture and the practical realities developers face daily.
His path in technology began with Fortran and a PhD in Computational Physics from the University of Lancashire, UK. Decades of hands-on programming experience since then have shaped his approach to architecting systems that serve developer needs. Paul remains active in the developer community through speaking engagements and writing, with a particular focus on JavaScript, Ruby, Swift and Rust.
Area of Expertise
Topics
Passwords are the oldest unfixed bug in software. Passkeys are the fix
In 1961, MIT's CTSS asked a user for the first password, and within a few years the password file had already leaked. Sixty years on, we are still shipping workarounds for the same bug: one-time codes, federated login, magic links. Climb that ladder rung by rung and a pattern appears: every layer relocates the shared secret (into a device, a provider, an inbox) without ever removing it. And anything with a shared secret can be phished.
Passkeys are the first widely deployed step that deletes the secret instead of moving it. This talk takes them apart from first principles: what a passkey actually is (a key pair, nothing more), why a stolen credential database becomes a list of worthless public keys, why one thumb-press is already multi-factor, and the detail that earns passkeys their reputation: the browser, not the human, decides whether a login page is genuine, which is what finally kills phishing by design.
Then we make it concrete. The two WebAuthn ceremonies, registration and authentication, reduce to one pleasingly symmetrical round-trip: a challenge out, a signature back. We'll build a live passwordless, usernameless login with the browser's native API and no JavaScript dependencies, and finish with the parts tutorials skip: account recovery, the second-passkey problem, bootstrapping the first account, and where the email address really fits (a label, not a credential).
You'll leave knowing exactly what happens when your thumb touches the sensor, and with a working recipe for shipping passkeys in your own app.
This talk is backed by a two-part written series on my blog ("Passkeys from first principles" and "Building passkeys in Ruby on Rails from scratch") and by passkeyed, an open-source Ruby gem I published that packages the approach.
Structure:
1. The bug report: MIT, 1961, the oldest open ticket in software.
2. Sixty years of workarounds: the authentication ladder of 2FA, federated identity and magic links, and why each one relocates the secret rather than removing it.
3. What a passkey actually is, and the two consequences: worthless breach dumps, single-gesture MFA.
4. Why phishing dies: the RP ID check moves site verification from the human to the browser.
5. The two ceremonies plus a live demo: passwordless, usernameless sign-in built with the native browser API.
6. The honest parts: recovery, the second-passkey problem, account bootstrap.
The core talk is framework-agnostic (the ceremonies are pure WebAuthn); the demo can be shown in Ruby on Rails or as plain HTTP endpoints depending on the audience. All diagrams and code are my own. I have spoken at iOSCon, DroidCon, dotSwift, DevTalks, and numerous other developer events and webinars; recordings are on my speaking page.
Trusting an AI is a hiring problem, not a model problem
Most advice about trusting AI is advice about picking a better model. That is the wrong lever, because you already know how to make an unfamiliar worker safe to delegate to, and you have never once done it by interrogating their intelligence. You write down what the job is, what it is not, and how the work gets checked.
In this session, we follow one small hiring decision all the way through. One day, whilst clearing my head on the elliptical machine, a thought occurred to me: I could ask the assistant that runs my knowledge base to recruit a personal trainer for me, meaning a role inside the system rather than a person. The interview it ran turned out to be more instructive than anything I had read about agent safety. It asked what the job was, then it asked the question that matters most: what must this role never do. It researched the profession before writing a line of the job description, and it finished with objectives concrete enough to tell later whether the hire was right.
Then the interesting part arrived. A trainer is not a clinician, which sounds like a platitude until the sleep data shows up, clinical readings included. Being allowed to read something is not the same as being allowed to interpret it, so the trainer reports how long I slept, names the direction it is moving, and says nothing whatsoever about what the clinical readings mean. Widening what a system may read never widens what it may claim, and confusing those two is behind a striking share of the AI failures people describe as hallucination.
From worked examples like the one above, I built out the six principles I run everything on, an acrostic called GOVERN: Gates, Origins, Verification, Evidence, Rules, and Nothing assumed. We will be looking at why a long list of permission prompts produces a system that feels governed and is not, why the honesty label has to travel attached to the claim, why anything countable belongs in a script rather than in a model's judgement, and why every ritual has to survive the previous one being skipped.
No particular stack is required to follow it, and nothing here needs a platform team or a budget: the whole system is folders, text files and version control, running on one laptop. You will leave able to write the job description for the next thing you delegate, whether that is an assistant, an agent in production, or a colleague on their first week.
This is a talk about governance told through a story, so it plays to a mixed room: engineers get the prompts, the scripts and the unattended runs, while leaders, product people and anyone using an assistant daily get the delegation frame without needing to read code. No live coding, and every artefact on screen is real and already published.
The material is not assembled for the CFP. GOVERN is published in full at pardel.dev/govern (coming soon, WIP), including the setup script and every prompt, and the system it describes has been running daily for three months: eleven deterministic scripts, three rituals, five gated actions, and a changelog of roughly 170 entries recording what was attempted, what failed and what was verified. The trainer in the story is a real role in it, with a research brief and a written mandate that draws a boundary across five health sources.
Structure (30 min; expands to 45 with the extended governance section and a longer Q&A):
1. The unanswerable question. "Can I trust it?" versus the question you answer every time you hire someone (3 min)
2. The interview. Role, name, the lane, research before writing, checkable first-week objectives, and why the lane question comes third rather than last (6 min)
3. Read is not claim. The trainer meets the sleep data, and a boundary that generalises to every agent you will ever deploy (5 min)
4. GOVERN, one letter at a time, each earned from the story rather than announced (8 min)
5. The short gate list. Why five gates govern better than fifty, and permission fatigue as a governance failure rather than a safety feature (4 min)
6. Deterministic first. Facts from scripts, judgement from the model, and what it costs to get that backwards (3 min)
7. What to write down on Monday, and close (1 min)
The 45-minute version adds the adversarial verification pass (a separate session pointed at each new artefact and asked to refute it rather than confirm it) and the rule that a system which works only while you are consistent is measuring your consistency rather than supporting it.
I have spoken at dotSwift, DroidCon, DevTalks and numerous other developer events and webinars; recordings are on my speaking page. All related materials are my own.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top