I had Engineering AI live-streaming on my office screen yesterday afternoon when Geoffrey Huntley gave his talk “The future belongs to people who can just do things“. It was the third time I’d heard this presentation this year, and I found myself nodding along to his point about the shift from ‘artisanal hand-crafted commits‘ to something much bigger. But this time, instead of thinking about what he was saying about the future of development, I was thinking about what he was saying about me.
The truth is, I’ve been wrestling with this for about a year now. Not the AI part – that’s been fascinating to explore through my own experiments and MCP work. But the identity part. The question of what I actually am.
I’ve been calling myself a ‘Code Wrangler’ for years – that’s my actual title at Automattic. It felt safe, a bit playful, definitely technical but not… presumptuous. Even though I’ve been comfortable talking about our ‘engineering’ team internally, something always held me back from claiming ‘engineer’ externally.
The gatekeeping felt real. Three quarters of a computer science degree but no graduation, no professional certifications, no clear credentialed path. I’ve been building my expertise through eight years of progressive work, from senior technical support engineer to developer to someone who thinks deeply about library architecture and explores emerging technologies like MCP. But somehow that voice in my head kept saying ‘but are you really an engineer?’
For the past year, I’ve been deep in the architecture of Automattic’s charts library. Not just writing code, but designing composition APIs, thinking through backward compatibility when refactoring positioning systems from absolute to flexbox, building context systems that other developers can extend. When I look back through those pull requests – from foundational Chart Context systems to sophisticated theme controls – I see someone making systematic technical decisions about how software should be built.
But I kept calling myself a ‘Code Wrangler.’
Yesterday, listening to Geoffrey talk about how ‘AI erases traditional developer identities – backend, frontend, Ruby, or Node.js,’ something finally settled into place. He wasn’t just talking about job titles disappearing. He was talking about what remains when the surface-level identities fall away: the capacity to think like an engineer.
At first I thought he was talking about AI tools automating code generation. But then I started thinking about what he calls ‘vibe coding’ – just shipping AI output without systematic thinking – versus actual engineering.
Engineering isn’t about what language you write in, or whether you have a piece of paper on your wall. It’s about how you approach problems. It’s thinking through system architecture, considering edge cases, designing APIs that other humans can actually use. It’s the difference between slapping together a quick fix and building something that can evolve.
When I designed that composition API for chart legends, I wasn’t just ‘doing React development.’ I was engineering a system that needed to be flexible enough for complex use cases but simple enough for basic ones. When I refactored absolute positioning to flexbox, I was thinking about maintainability, responsive behaviour, cross-browser compatibility. That’s engineering thinking.
The more I thought about it, the more I realised that what separates engineering from just writing code is thinking beyond the immediate problem. When I was consolidating that scattered sample data across hundreds of lines of Storybook stories, I wasn’t just cleaning up – I was thinking about scalability. How do we maintain this as the library grows? How do we prevent this duplication from happening again?
That’s engineering thinking: building antifragile software that gets stronger under stress rather than breaking. When I built those composition APIs, I was designing for the unknown future use cases we haven’t thought of yet. When I created that AI-friendly development guide, I was anticipating how development workflows are changing.
Even working solo on the charts library, I’ve been unconsciously applying project management practices – breaking down complex features into incremental PRs, managing technical debt, thinking about migration paths for breaking changes. That systematic approach to work isn’t ‘project management’ as a separate skill – it’s how engineers think about building sustainable systems.
I’ve been applying engineering principles all along , just wasn’t calling it that.
Sitting at my desk yesterday afternoon, watching the talk wind down, I had this quiet realisation: I’ve been doing engineering work for years while calling myself something else. Not because I wasn’t qualified, but because I thought ‘engineer’ belonged to people with different credentials than mine.
But if he’s right – if AI is about to dissolve all those traditional identity boundaries anyway – then maybe this is exactly the right time to stop gatekeeping myself out of a title that actually describes what I do.
I think about the systematic way I approach technical problems, the architectural decisions I make, the way I think about scalability and maintainability. I think about building APIs that other developers can extend, designing systems that handle edge cases gracefully, creating documentation that helps teams work more effectively. That’s not ‘code wrangling.’ That’s engineering.
So I’m making a change. I’m calling myself an engineer. On my blog, on LinkedIn, in conversations about my work. Not because I suddenly became something different, but because I’m ready to claim what I’ve been all along.
Leave a Reply