Designer, PM, Engineer — AI is blurring the lines [Hamza Oza]

Hamza Oza00:15

People who know how to extract the most out of these systems with the least friction, who can get to those good outcomes — those are the people that are going to survive. And it doesn't really matter if I'm called a designer, if I'm called a PM, or if I'm called an engineer.

James Mulligan00:33

Okay. It is apparently recording.

Hamza Oza00:36

I can see a big red flashing indicator, so we're good.

James Mulligan00:41

Okay. Right. Well, let's start with — where do you work, Hamza? Tell us about your company.

Hamza Oza00:47

Yeah. Hi, my name is Hamza. I'm a designer at Tessl. We describe Tessl as like a control plane for how organisations use AI agents. So if you think about most teams right now, they're probably using AI in some kind of ad hoc way where you're copying prompts around. Maybe you've created some skills, but you're probably sharing them through Slack. There's little to no versioning of any of these things, and it's kind of hard to know what's working and what's not working — who's owning some of these things and not owning some of these things. And so we're trying to help bring some structure to that for organisations. A way to package, to measure and trust these skills and the context that power these agents.

Hamza Oza01:25

So maybe in a more concrete way, think of it like NPM, but with some of that governance and evaluation and observability built in alongside that. I'm also visiting tutor at the Royal College of Art, where I coach second year master's students in design and AI, which probably gives me a different spin on how some of the space is evolving.

James Mulligan01:46

Yeah, amazing. Can we just spend a little bit of time on the Tessl piece? What's the pain point you're trying to address, and who has that pain point?

Hamza Oza01:57

I think the biggest pain point that we're looking at is — are the things that I'm using actually making my agents better and more effective at producing those outcomes and results?

James Mulligan02:12

What's a good example?

Hamza Oza02:12

So let's say I'm a developer who wants to code the next feature. Often one of the things that I run into are things like the side effects of vibe coding — I maybe get hallucinated code that's referencing documentation that doesn't exist anymore, or has changed because the package I was using has updated. Maybe it's missing some context around my business, and maybe it's completely ignored things like the components that I may have created in the past — it's just inventing new ones and just adding code spaghetti, or maybe missing some of the standards that you might have as an organisation in terms of how you define what good engineering looks like.

Hamza Oza02:53

And so what we help you do is understand — actually, are these skills or context or rules or docs that you've created actually making a difference? Or are they just bloating your window and making you eat up more tokens and pay more for your AI than you need to? Could you be using a cheaper model to achieve the same or similar outcomes? So maybe there's an efficiency gain here. That's the kind of bucket of problems we're trying to help organisations with.

Hamza Oza03:14

And that's at a developer level. But of course, when I'm an organisation and I have 50,000 developers, it's like — well, how am I performing across the organisation? So the standard AI challenges that we've had in the past were: I'm investing a lot of money in this AI, I'm investing a lot in these models and agents — are they actually making a difference to my organisation? Where are they contributing? Where are they not contributing? How can I be more strategic about my investments?

James Mulligan03:48

Yeah, interesting. So I guess on the one hand, it's good old-fashioned engineering best practices and trying to apply that to the agents that a lot of these institutions are now frequently using to do these tasks and to execute code for them. And then I missed the model piece, which I hadn't really thought about, but I guess it's — can you spend less to achieve the same, just by improving the standards that sit around it? Which is fascinating, because that applies to people as well, doesn't it?

Hamza Oza04:18

It does. And actually, some of the work that we've done around our evals work has shown us that for many cases, what you could do is — a well-written, well-structured skill with a maybe cheaper model can actually give you just as good outcomes as a model that is high performing but costs you more. So what it does is give you sufficient guardrails to be able to leverage that tooling and therefore reduce the operating costs as an organisation.

James Mulligan04:52

Yeah, got it. And where does Tessl fit into this now broad infrastructure that is emerging to support agents generally? You've got your model providers like Claude, and then you've got this broad emerging concept around best practice skills that can be made available within a code base. Where does Tessl fit into that?

Hamza Oza05:16

I would think of it as your ability to manage that layer of skills and context. So we sit above the model, but probably before your agent, if that makes sense. So you, as a user interacting with your agent — we kick in and say, well, did you load this skill? Because maybe a user has activated a certain keyword. So for example, I want to do this change in front end, or actually I want to rewrite my docs, and so it should reference these skills, etc. We probably sit in that middle layer of the stack and then use that as a distribution mechanism.

James Mulligan05:52

Yeah. I guess what's fascinating about that is that the skills really — it becomes quite multi-dimensional. You could give an agent access to a design system and suddenly start designing things similar, but then it also goes to how do we handle things like versioning, and the language you use within code, and all these sorts. There's just a lot to it.

Hamza Oza06:15

We've only talked about dev-focused skills. We've not even talked about non-engineering workflows.

James Mulligan06:23

Oh, interesting. Okay, double click on that very quick.

Hamza Oza06:25

So I'm a designer, right? And I'm usually at the intersection of things like marketing but also engineering. We have a tone of voice or a brand that we want to represent. So how do we make sure that translates into the product copy or the UI or the documentation?

Hamza Oza06:42

At a higher level, those feel like two distinct things. You're saying — well, that's marketing and that's in its own world. They have certain rules they want to follow, and it's often things like voice, visual style, your communication style. You want to be fun or punchy or serious and very stiff because of enterprise and security and all those things. But then that should translate into your product UI, right? The way you give instructions, the way you provide error feedback. And so this allows us to connect a lot of those bridges together, because now I can encode some of that into a skill as part of my design system, let's say. And now that's available, so even if someone is creating a new feature, hopefully you can embed a lot of your organisational standards into this directly and have it picked up.

James Mulligan07:39

Organisational standards. Yeah, I love it. That sounds like principles. And so, Hamza, talk a little bit about your role at Tessl. So you're a designer?

Hamza Oza07:48

Yeah, so I'm leading the design team here at Tessl. And right now, I think a big part of my role is shaping how the product comes together end-to-end. So it's not just about refining and designing those interfaces, but also thinking about the core concepts, the primitives, and how we actually use those in practice. Because the context engineering space is still relatively new — a lot of the patterns aren't established, many of the workflows are still emerging. And as a result, a lot of those implications aren't obvious to anyone. We can all crystal-gaze some of this, but we'll see over time how it's going to manifest.

Hamza Oza08:31

So a lot of it's around creating that structure, figuring out — actually, what is a skill in itself? What does it mean for organisations? How do they behave? How do you evaluate them? How do they even fit into that developer workflow, or as we were talking about, non-developer workflows? Coming back to a more concrete example, when a developer is thinking about installing a skill to use with their agent — is it actually going to make a difference? Is it going to make my agent better? Am I going to have to just rework the stuff that it spits out?

Hamza Oza08:50

And so thinking of ways to answer that cleanly — thinking about evaluation scores, version history, visibility into how it performs across those different models. Because otherwise it's all about that black box problem. You're asking them to trust things and they don't really know.

James Mulligan09:12

These are all new patterns as well, aren't they? They're all new patterns for this entirely new paradigm around agents and how they might work in an organisation. And just from a design perspective, you're having to think about stuff that's never been done before.

Hamza Oza09:28

Never been done before. So it's a lot about taking those abstract things and concepts and making them tangible. I think good design has great power in that — giving people the ability to use that with confidence and figuring out, okay, if I use this thing, I'm not going to completely nuke my code base, I'm not going to suddenly delete prod by doing any of these things. So yeah — finding new patterns for a new space, turning those abstract AI concepts into something developers can trust and actually use.

James Mulligan09:57

Yeah, so cool. And what I love about this is that the whole point of these conversations is about getting perspectives from people that are not just at the cutting edge, but are actively building, to understand what this future looks like with AI, with agents — because it gives them a first row seat to how their own role is going to change. I think you've already touched on a few points there around context engineering and what that means for design and non-engineers. But how do you see AI — and of course when I'm saying AI I'm talking about LLMs and agents and this new flavour of AI rather than the machine learning of a decade ago — how do you see that changing your role as a designer?

Hamza Oza10:44

First of all, I think more than anything else, it's a fun playground. I don't think I've had as much fun building as I've had at any given point in time. It just gives you lots of new opportunities. Thinking about how my job may have changed or evolved — there's probably three layers to this. For me as an individual, I think the biggest shift definitely has been speed and judgment and fun. I can actually raise my ambition quite significantly because of all this. I can explore more of the design space, I can test ideas much faster than before. Personally, I was always quite comfortable getting into code and opening PRs, but I used to be the exception. Now it's becoming more and more of the norm.

James Mulligan11:31

When you talk about exploration and going further with that exploration, is that what you mean? Do you mean taking your designs and building them, and then seeing how they perform and being able to get feedback on them?

Hamza Oza11:42

Yeah, so across two dimensions. You can start off wider earlier as well. Maybe before, I would have had time to do three concepts — maybe I can now do six or seven. So I can explore that wider. And then once I feel confident in maybe two or three of those directions, you can go deeper in them as well. So across both axes, I would say.

James Mulligan12:04

And this is probably a simplistic question — what are you using? What's enabling you to be able to do that?

Hamza Oza12:11

So I'm using right now probably a combination of Figma. I still do use Figma a bit, especially for high — like, bespoke visualisations and those types of stuff. So Figma, sketching and those things, and then a combination of Cursor and Claude Code.

James Mulligan12:28

Interesting. And why the combination of the two? Is that a preference thing?

Hamza Oza12:33

Yeah, it's more of a preference thing. With Cursor, just having an IDE open and being able to use it — also because, like I said, I was comfortable using VS Code in the past and opening PRs and stuff. So for me that feels like a natural evolution. And then connecting that to Claude Code, just because I think the outcomes tend to be a lot better for the work that I'm doing. When you combine Figma's MCP with Claude Code, at the moment it feels like that stack works quite well. You still have a few issues here and there, but in general, 80 to 90% of the way gets you quite close.

James Mulligan13:15

I'm going to have a little label up in the corner here to say what the date was, because all of these tools will be completely different in a week's time. And Cursor has just been acquired by SpaceX or something, hasn't it? So who knows what that will look like in a month.

Hamza Oza13:30

And then I actually use ChatGPT for a lot of image generation, which maybe is surprising for people because I'm not using Midjourney instead. Because I find actually once you give it guardrails, it's actually much better at giving you more consistent images, at least in my use cases.

James Mulligan13:51

I mean, it's just reinforcing everything you just said about Tessl and the context engineering piece — what the instructions, the quality of the instructions you get. It's difficult to reflect on this at this point, it's moving so quickly. But if you were a new designer, if you were getting into design for the first time today — and maybe actually, can we go back to what you were talking about in terms of your lecturing, and maybe you can reflect on some of that — but what is the advice you're giving to people that are just getting into design, or they're figuring out what AI means for them? What's your advice?

Hamza Oza14:24

Yeah, it's a great question, because I think there are probably a couple of points here. When I look at those people kind of early in their career, the shift that I'm seeing in terms of their mindset and attitude — and that's not to say it's not the case elsewhere or it hasn't been in the past — but maybe a greater emphasis on outcomes and exploration. With my students, I think they're less attached to specific roles and titles. They're not thinking in disciplines in the way perhaps I would have done when I was a student. They're thinking more about — I've got this problem to solve, what are the tools that can help me get there? And AI can really, really amplify that. It helps them explore more of those surface areas and helps them think about what are the different things they can try. They don't have a pre-world like we do. They don't know what the before and after is. For them, it's just the after.

James Mulligan15:15

Yeah, it's so interesting. I can remember coming up in building software in advertising, and getting into project management. Two years in, the idea that I would have been able to become an engineer or a designer — nope, you're a project manager now, that's what you do. I love that frame — that actually it's less about the role and the title, it's more about the outcome and feeling empowered to get there, regardless of discipline.

Hamza Oza15:40

The two caveats that I would then — because you were asking what advice I would also give them — the first is, do not let these tools rob you of your critical thinking. That's the biggest one. Because you don't want these students who are early in their career just taking those things verbatim and then not applying their judgment or their level of understanding, or not interrogating the outputs in the way they perhaps should be. And I think that's probably where they lack a little bit. They don't have an experience to base some judgment off of. So my biggest thing is — interrogate it, try and understand the why behind it. Yes, it gives you a lot of these things, but it also gives you lots of noise. You really want to think about why are you saying yes to something. And you should be saying no to lots of things as well, but understanding why that's the case.

Hamza Oza16:39

Whereas if you're a bit later in your career like us, we have that experience to base judgment off of. For us, maybe execution gets faster and we can automate some stuff — and we should definitely be automating a lot of stuff. But knowing what to build, what to trust, what to ignore, becomes the bigger problem. And that's where the experience compounds. Because if I do have 55 prototypes, I have to say no to the 54 as well. And I have to know why I'm saying no to those.

James Mulligan17:01

Yeah. And so I guess especially from a design perspective, there's a degree of subjectivity. What does good look like to every designer? It looks slightly different. What does good look like to every engineer, I guess.

Hamza Oza17:13

And also users, right? Because if you're giving users more variety, then by nature many of them are going to level out. Some are going to say, well, I like this one. The others are going to say, I like this one. And suddenly you're like, well, we've got an equal split. What do we do?

James Mulligan17:32

Oh, I don't like that. But you're right — you give everyone an unlimited amount of options, you're going to end up with something beige, aren't you?

Hamza Oza17:39

Now you've got choice for analysis. Because before, we used to use user testing as an external way of breaking maybe internal deadlocks.

James Mulligan17:48

Interesting, okay.

Hamza Oza17:49

How do you now do that? Because now you can give users infinite options. And everyone feels like they have good taste and all those things. So how do you start showing the good from the great? It's an interesting dynamic. We still don't know what the implications are, and I'm quite curious to see how things go.

James Mulligan18:14

Yeah. But I mean, you're on the front line both in the way that people are being educated and the way it's being built. So it's a lucky position to be in. Right, so the big question — what is your prediction for the future? Obviously there's a lot of people on LinkedIn and networks, from big consultancies all the way down to solo influencers, making big statements — which discipline is dead, that this one's over, all these sorts of things. But you're on the front line. What do you think will be true in a year's time in terms of the way we work and the way we build products?

Hamza Oza18:49

Yeah. I think if I stick to that theme of early versus later in your career — I think the future of work is maybe less about specific roles and more about leverage. It always used to be as well, but I think this just gets amplified even more. People who know how to extract the most out of these systems with the least friction, who can get to those good outcomes — those are the people that are going to survive. And it doesn't really matter if I'm called a designer or if I'm called a PM or if I'm called an engineer. I think the product trio, in the way we classically split it in the past, probably doesn't exist.

James Mulligan19:25

And the product trio — you mean design, engineering, product?

Hamza Oza19:28

Yeah. I think maybe that doesn't exist. So when I think about how even I collaborate at a team level, thanks to AI, the boundaries have become incredibly less rigid. Designers have become much closer to implementation. The engineers I work with have become even more involved in shaping product behaviour. Maybe as a tangible example — I used to hand over Figma files, now I'm handing over PRs. And so we're still trying to figure out what that means. Should I just be doing dummy front end, or should I also be including database connections and pure backend work? Maybe that's a bit too much.

James Mulligan20:02

Comes back to the outcome, doesn't it?

Hamza Oza20:04

It comes back to the outcomes. If I'm someone in an organisation who's trusted to say — well, we're noticing problem X in our product, go solve it — does it really matter if I stop arbitrarily at Figma, or here's a release candidate ready for people to test? I don't think so. And so that's where it comes. We had ownership of outcomes before, but they were perhaps cleanly defined to roles. Now it's going to be defined to individuals, based on whether it's their preference, maybe their affinities to different types of tooling, or maybe certain types of problems, etc. I think that's where we'd end up.

James Mulligan20:47

So you see the lines blurring, and the rigid design of product teams in the past also changing to be potentially more fluid. But I guess your point earlier about craft and taste still matter, of course. So an individual that does take it end-to-end is probably going to need to have some experience across all of those disciplines to be able to do that. So then does it get reduced down to that question of expertise? Do you end up partnering with someone that has their 10,000 hours in, and can figure out what a good design looks like if you've never touched a design before? How do you see that working?

Hamza Oza21:29

Yeah, it's an interesting question. Because I guess the design world, in my opinion, has already faced that. You used to have visual design, user researcher and UX designer as three separate roles. Over time, they collapsed into the product design role because the tooling improved, the way we worked changed. So that was maybe one level of collapse. Now we're seeing it happen in a more cross-functional way. And I think it's more about you as individuals — what spikes you have and what do you care about and what kind of professional you want to be. As a result of that, you might gravitate towards different people that you collaborate with. I really like James because he's got an incredible way of writing, so I want to leverage his toolkit in terms of microcopy and those things. But maybe someone else is — oh, they're a brilliant engineer, and they're able to really collapse complexity into a simple architecture that we can deploy quickly. So yes, people will stack their own backgrounds that they leverage on, but that doesn't mean they won't be able to tiptoe in other places.

James Mulligan22:47

I love that. I think that's a great prediction. And it's really interesting that you brought up that product design example, because you're right — this idea that specific individuals would be responsible for specific skills has already started to collapse in lots of areas. Yeah — collapse is the wrong word. I think it's just become democratised, in the sense that anyone can have a spike in multiple different skills. Does it matter if two of those skills are in design and three of them are engineering and two of them are in product? Who cares?

Hamza Oza23:18

Especially if I'm a business with an outcome — does it really matter? You know, so-and-so calls themselves this, but at the end of the day they manage to achieve what we need. That's probably enough. I don't know what that means in terms of progressions and standardisation and how do you shift from one company to another and how you articulate it. But in the creator economy, there's a whole thing about self-branding and those things. Maybe parts of that then start eking over into the tech world, and you're like — well, I'm so-and-so who's good at this. And contractors have had to do that all the time as well. So I don't think these are new things personally, but it just means more people are probably impacted by it as a result. They have to figure out how do they fit into this jigsaw puzzle.

Hamza Oza24:12

And I'm not claiming I know the answer to that for myself. I'm still trying to figure out — who am I, Hamza, as a designer? Do I still lead with that as a title, like, I'm a hands-on designer, or hands-on product person? But that feels a bit weird. I don't know.

James Mulligan24:30

To be honest, even in institutions where those lines are beginning to blur, we used to default to product builder. Builders has become a generic term, I guess, for people that do more than one thing. You know, I'm now concerned, Hamza, that that might be the most serious prediction we get. I think it's just downhill from there.

Hamza Oza24:53

It is. Everyone else is saying, you know, we're going to all wear hats and rotate around, and depending on what axis it's on, now you're going to be a PM, then you're going to be an engineer, then you're going to be a designer. It might just be like a real-time sorting hat.

James Mulligan25:09

Yeah, yeah, yeah. Nice. Okay, we'll do both predictions and see which one comes true. That's awesome. Thank you so much for sharing your experience. I think it will be incredibly valuable to a lot of people. And we'll connect again in a year's time and see which one came true.

Hamza Oza25:26

Well, if you bring me, I'll know.

James Mulligan25:28

Which one of those came true.