What's In A Name?

I’ve only once held a job title with “developer” or “programmer” in it, some twenty years ago. I don’t have a computer science degree. And yet I’ve spent the majority of my career making software.

For most of the last decade my github contributions were pretty barren. Then I started playing around making little widgets, editing html and javascript files and lurking on StackOverflow. Then ChatGPT came along. And Replit made infrastructure really easy. I spent 18 months copy-pasting code and errors between chats and my files and environments. Then Cursor came along. And everything else came along, faster and faster.

Now I’m working directly with AI coding agents. I review what they produce, I ask questions, I guide the architecture - but the actual code is AI-generated.

So what am I?

The traditional gatekeepers would have an answer ready: “Not a real developer.” But here’s the thing - the software I’m building works. It solves real problems, albeit for a small group of people. It follows good engineering practices - high test coverage, appropriate security, sufficiently resilient architecture. The fact that I orchestrated its creation rather than typing every character doesn’t change the outcome.

I still don’t consider myself to be a developer, but if it looks like a duck and quacks like a duck. (For the record, I neither look like a duck nor quack like a duck). But I am now reflecting on how our professional boundaries are evolving.

Walk into any tech company and you’ll find an elaborate taxonomy of roles: Frontend Developer, Backend Engineer, DevOps Specialist, Solutions Architect, Technical Product Manager. Each with their own swim lanes, their own conferences, their own LinkedIn hashtags.

These distinctions aren’t meaningless, they reflect genuine differences in focus and expertise. But they’re also deeply contextual. A “full-stack developer” at a three-person startup is doing completely different work than someone with the same title at Meta. The “technical product manager” role exists at some companies and is considered an oxymoron at others.

Organisations create these boundaries based on their specific needs, scale, and history. What counts as “technical enough” varies wildly. I’ve seen product managers who could debug complex backend issues dismissed as “non-technical” because they didn’t write the fix themselves. I’ve seen developers who couldn’t articulate why they made certain architectural choices celebrated as technical wizards because they wrote a lot of code.

The boundaries are real in their consequences, they determine who gets hired, who gets listened to in technical discussions, who feels like they belong. But they’re somewhat arbitrary in their construction. There’s no natural law that says the person who types the implementation details is more “technical” than the person who designs the system architecture or evaluates whether the solution actually works.

The rapid improvement in AI coding tools isn’t creating this ambiguity, it’s exposing it. When Claude or Cursor or GitHub Copilot can generate working code from a clear description, suddenly we have to confront that the work has changed.

I’ve been thinking about these questions for a while now, and obviously I’m not alone. In February 2025, ThoughtWorks convened senior engineering practitioners from major technology companies for a multi-day retreat to wrestle with exactly these questions. The findings, published recently, reveal an industry at an inflection point.

Annie Vella, one of the participants, coined a term that crystallised something that people are experiencing but hadn’t named: the “middle loop” of supervisory engineering. Software development has traditionally been described in two loops - the inner loop of writing and testing code, and the outer loop of delivery and operations. What’s emerging now is a third loop in between: the work of directing, evaluating and fixing the output of AI agents.

This middle loop requires different skills than writing code. As the retreat identified, the people excelling at this work tend to:

• Think in terms of delegation and orchestration rather than direct implementation

• Have strong mental models of system architecture

• Can rapidly assess output quality without reading every line

The retreat also grappled with the same tensions I’m exploring here. They noted that many developers “were hired specifically to translate pre-digested tickets into working code. That work is disappearing.” They observed that PM and developer roles are converging to the point where some companies are researching whether the PM role needs a new name entirely.

What struck me most was their honesty about not having answers. The retreat “didn’t produce a roadmap,” the summary notes. “It produced a shared understanding that the map is being redrawn and that the people best positioned to draw it are the ones willing to admit how much they don’t yet know.”

That feels right to me. We’re all figuring this out together.

If writing syntax isn’t the essential skill, what is? Let’s be honest about what’s required to build good software.

Understanding the problem deeply enough to know what needs building. This is harder than it sounds. It’s the difference between “we need a reporting dashboard” and understanding that finance needs real-time visibility into cash flow because monthly reports arrive too late for them to make procurement decisions. The clearer your mental model of the problem, the better the solution you’ll build - whether you’re writing code or directing an AI agent.

Breaking complex problems into addressable pieces. Good software architecture isn’t about knowing every design pattern by heart. It’s about recognising that this monolithic process should probably be broken into services, or that this data needs to live separately from that data, or that these two concerns shouldn’t be coupled together. Can you learn this without a CS degree? Absolutely. Does it help to learn from people who’ve seen systems fail in predictable ways? Also yes.

Judgment about trade-offs. Every technical decision is a trade-off. Performance vs. maintainability. Speed to market vs. getting it right. Building custom vs. using existing tools. The person closest to the problem often has crucial context for making these calls, but only if they understand enough about the technical implications to reason about them.

Mental models of how systems behave. When your application slows down, can you reason about why? When it crashes, can you form hypotheses about what broke? When you’re reviewing AI-generated code, can you spot the pattern that will cause problems at scale? This is knowledge you build through experience and learning, not through credential-holding.

The ability to evaluate whether code actually solves the problem. The AI can generate syntactically perfect code that completely misses the point. Someone needs to be able to look at a solution and ask: Does this actually do what we need? What happens in edge cases? What assumptions are baked in that might not hold?

Here’s where I need to be careful, because I don’t want to dismiss the value of formal CS knowledge. Understanding data structures, algorithms, security principles, how databases work, what happens at scale; these things genuinely improve your ability to build robust systems.

But here’s the question: why shouldn’t anyone building software be able to learn these things?

A journalist learns to verify sources and separate reporting from opinion. An architect learns about load-bearing structures and material properties. A project manager learns to identify dependencies and critical paths. These are all domain-specific thinking frameworks that improve outcomes.

CS fundamentals are the same; they’re useful mental models for making better decisions about software. They’re not magic knowledge restricted to people with the right degree or job title.

If someone’s building an application and AI generates code that loads all records into memory before filtering them, they don’t need a CS degree to realise “wait, this will break with a million records.” They need:

• Context about their actual usage patterns

• Enough understanding to ask “how does this handle scale?”

• Willingness to learn what solutions exist when they hit a problem

• Ability to recognise warning signs

The person closest to the problem - the healthcare worker building a patient tracking tool, the researcher creating a data analysis pipeline, the operations manager automating a workflow - often has crucial judgment even without formal training. They know their domain. They understand the constraints. They can evaluate whether a solution will actually work in practice.

What they need is access to the fundamental concepts, not permission from gatekeepers.

I taught myself HTML, CSS, and JavaScript at university for a project. Not because I wanted to be a developer, but because I needed to build something and those were the tools available. In my first role, I scripted and coded because it was the most effective way to solve problems I was facing.

Then I spent most of my career in product, working with engineers. I was doing technical work - architecting systems, making architectural decisions, evaluating implementations - but never with a developer title. I existed in that undefined space between “technical” and “non-technical” that organisations are always uncomfortable with.

About 18 months ago, I went hands-on again and actually hand-wrote code. It was useful - it built mental models that help me now. But it turned out to be a temporary phase. The AI agents got good enough that writing code myself became inefficient. Why would I spend an hour implementing something when I could describe what I need and review the result in ten minutes?

So now I work directly with coding agents. I still do all the substantive work - I understand the systems I’m building, I make the architectural decisions, I evaluate whether solutions actually work, I debug by reasoning about system behaviour. The only thing that changed is who (or what) types the implementation.

The traditional narrative says I should feel like an impostor. That without hand-writing code, I’m not “really” technical. But the software still gets built. The systems still work. The problems still get solved.

Maybe the traditional narrative was always backward.

Here’s what I want you to understand if you’re reading this and thinking “but I’m not a real developer”:

If you have domain expertise, problem-solving instincts, and curiosity about how systems work, you already have crucial ingredients for building good software. The barrier was never your fundamental capability. It was access to implementation tooling.

That barrier just dropped dramatically.

This doesn’t mean everything is suddenly easy. Good engineering practices still matter. Building systems that are performant, reliable, secure, and maintainable still requires understanding and care. Experts who’ve seen systems fail in particular ways still bring valuable pattern recognition.

But here’s the shift: that expertise becomes more accessible when you can have a dialogue with AI tools and ask experienced developers targeted questions about the choices being made. You don’t need to spend years learning syntax before you’re “allowed” to think about architecture.

Here’s where I need to complicate my own argument a bit. Just because you can now build software doesn’t mean you always should.

There’s another phrase going around the industry at the moment: the so-called Mexican stand-off between Product, Engineering and Design. If Product Manager can get AI to produce designs and write the code, what need of those other parts of the product trio? And the same goes for each of the other disciplines.

If you’re a product manager, where do you actually add the most value? Is it in implementing features, or is it in discovery work: deeply understanding customer problems, making commercial judgments about what to build, engaging with users to validate assumptions?

There’s a real risk that the accessibility of AI coding tools becomes a distraction. You could spend your afternoon building a prototype when you should be talking to customers. You could optimise database queries when you should be figuring out if you’re solving the right problem at all.

For a long time there’s been a trend toward “T-shaped” or even “comb-shaped” people: professionals with broad coverage and deeper skills across multiple disciplines. AI accelerates this trend by making it easier to be competent across more domains.

But is that always the right move?

At a start-up, being able to wear many hats is genuinely valuable. When you’re three people trying to ship something, the person who can do customer development, design interfaces, write copy, and implement features is incredibly leveraged. The overhead of coordinating specialists exceeds the benefit.

As organisations scale, the calculus changes. A product manager who can code might be less valuable than a product manager who’s exceptional at strategic thinking and user research, paired with engineers who focus full-time on technical excellence. Depth starts to matter more than breadth.

I don’t have a universal answer here. The right balance depends on:

• The stage and size of your organisation

• What your unique strengths are

• Where the current bottlenecks actually are

• What the opportunity cost of your time is

If you’re a domain expert and there’s no one to build the tool you need, building it yourself makes perfect sense. If you’re a product leader at a 500-person company with a team of experienced engineers, maybe your time is better spent on strategy than implementation.

The accessibility of AI coding tools creates a choice that didn’t exist before. But it’s still a choice. Just because you can doesn’t mean you should. Ask yourself: is this the highest-leverage use of my time right now?

Sometimes the answer is yes: building helps you understand the problem space better, or moves fast enough to unlock learning you couldn’t get any other way, or solves a problem no one else has capacity for.

But sometimes the answer is no, and recognising that is just as important as recognising you now have the capability.

Let me be clear: experienced engineers bring genuine value. They know why certain architectural choices create problems six months down the line. They understand the subtle security implications of different approaches. They’ve built intuition from seeing systems fail in predictable ways.

But here’s what changes: that expertise gets amplified, not diminished. An experienced engineer who previously spent 60% of their time on implementation can now spend that time on architectural review, identifying systemic risks, and teaching. Their judgment can now be brought to bear much more rapidly and without the concern that they should be writing code.

This expertise doesn’t disappear in an AI-enabled world, it becomes more focused on what humans do best. Instead of spending time on implementation details, experienced engineers can focus on:

• Reviewing architectural decisions with domain experts who are now building directly

• Identifying patterns that will cause problems before they manifest

• Teaching fundamental concepts in context, as people are actually building

• Focusing on the genuinely complex problems that require deep technical expertise

• Applying their hard-won pattern recognition across more projects simultaneously

The conversation shifts from translation (“please turn these requirements into code”) to collaboration (“here’s what I’m building, help me understand these trade-offs”).

That’s not a diminished role. It’s a massively more leveraged one.

Here’s where I want to reflect on the narrative that roles are collapsing into each other. Yes, the ThoughtWorks retreat noted that PM and developer roles are converging. My optimistic view is that the product trio - product manager, engineer, and designer - can now operate at a completely different level of effectiveness.

Think about the classic product trio working pattern:

• The PM understands the market, the business model, and what problems are worth solving

• The designer understands user needs, interaction patterns, and how to make complex things simple

• The engineer understands technical constraints, system architecture, and what’s actually possible

AI doesn’t erase these distinct expertise areas. It should help remove the friction between them.

The PM can now prototype their idea and have a concrete conversation about feasibility rather than writing abstract requirements. The designer can build working interactions and test them with real users rather than defending static mocks. The engineer can explore multiple architectural approaches and compare actual implementations rather than debating hypotheticals.

Each person’s core expertise becomes more valuable because they can now express it in working software. The PM’s market intuition, the designer’s user empathy, the engineer’s systems thinking - all of these get amplified because the gap between concept and reality shrinks.

The danger is thinking “now the PM can code, so we don’t need engineers” or “now the engineer can prototype UIs, so we don’t need designers.” That’s the wrong lesson. The right lesson is: now the PM’s product judgment can directly shape working software while the engineer’s architectural expertise reviews and refines it, while the designer’s interaction principles guide both, all happening in tight loops instead of sequential handoffs.

My optimistic take is that the roles aren’t collapsing, rather they’re finally able to actually collaborate the way we always said they should.

One person with domain expertise and an army of AI agents can accomplish remarkable things. But a team of people with complementary expertise, all augmented by AI agents? That’s genuinely powerful.

Think about it: the domain expert who deeply understands the problem space, the experienced engineer who’s seen similar systems at scale, the designer who understands user needs, the operations person who knows how things break in production - each of them can now work at a higher level of abstraction, with AI handling implementation details.

The collaboration becomes richer because people can prototype their ideas and have concrete conversations about actual working code rather than abstract requirements documents. “Here’s what I built, what am I missing?” is a different conversation than “here’s what I think we should build, can you do it?”

Disagreements surface faster when people can try different approaches and compare actual results. Learning happens faster when team members can see how others solve similar problems. The collective knowledge of the team compounds rather than getting bottlenecked through whoever has time to write the code.

This isn’t about replacing collaboration with isolation. It’s about enabling collaboration at a different level - one where more people can participate in technical decisions because the barrier to demonstrating ideas has dropped.

I wrote the previous section very much from the perspective of amplifying the status quo. This is not necessarily how things will play out. My belief is that the skills are more important than the roles, and in the previous sections I’ve used the roles as short-hand, and am addressing the current state of the world.

The important thing is the necessary skills, some of which are changing and some of which are the same but will be given more time and visibility.

There is an emerging consensus that the more abstract human abilities such as taste are going to be increasingly important. Then I saw this on X:

Nan Yu@thenanyu

I hate to break this to everyone, but you probably don't have better taste than the AI. If you ask any leading model about a product decision with guidance: "don't tell me to ask users; just reason through it yourself." It will give you a better answer than 90% of PMs. A lot

3:21 PM · Feb 18, 2026 · 376K Views

186 Replies · 39 Reposts · 766 Likes

And whilst the actual number is something other than 90%, I think the sentiment is directionally correct. Taste is hugely subjective and a machine that has processed massive volumes of expressed human taste is likely to produce something reasonable. It is unlikely to outperform a deep expert in a specific field, but that’s not most people.

Taste is built from an accumulation of experiences and decisions.

Agency and curiosity are vastly more important attributes than taste, particularly given you can now rapidly accumulate experience and decision making skills by building and gathering feedback, accelerated by these new tools.

The other thing to note is that AI is creating the opportunity to reimagine the tasks that are needed to develop products. And if a role is essentially a collection of tasks, what happens to roles when the tasks change?

Here’s something important I need to say clearly: if you’re stepping into building software with AI tools, you’re stepping into a discipline with real consequences. You can’t just prompt your way to good software and assume the AI will fill in the gaps.

AI will happily generate code that looks clean but has subtle security vulnerabilities. It will create database schemas that work fine with 100 records but collapse at scale. It will implement features that technically meet requirements but create terrible user experiences or future maintenance nightmares. The AI doesn’t know about your specific context, your users, your constraints, or the downstream consequences of the choices it’s making.

This means you need to develop real understanding, not just the ability to generate code. You need to learn why certain patterns exist, what makes systems secure, how to evaluate trade-offs, where things commonly break. You need to respect the craft that experienced engineers have spent years developing.

The good news? AI can actually help you speed run this learning - if you use it right.

Instead of just accepting the code AI generates, interrogate it. Ask “why did you structure it this way?” Ask “what are the security implications?” Ask “how would this perform at scale?” Use AI as a tutor, not just a code generator. When something breaks, dig into why rather than just asking the AI to fix it.

Build small things first and actually deploy them. Feel the pain of debugging production issues. Learn what happens when you skip input validation or ignore error handling. Get forced to upgrade your Vercel account because you forgot to enforce rate limiting and OpenAI’s scraper got hold of your site (hi, it’s me). Make mistakes in low-stakes environments before you’re making them in systems that matter.

Pair with experienced engineers when you can. They’ve seen the failure modes. They know which corners are dangerous to cut and which are fine. Their pattern recognition is hard-won and genuinely valuable. Learning from them while you’re building with AI tools is massively more effective than either approach alone.

The engineers who’ve been doing this work for years aren’t gatekeepers to resist, they’re experienced practitioners who can help you avoid painful mistakes. Approach with humility and genuine curiosity about what they know. Most engineers are happy to teach people who demonstrate they’re serious about learning the fundamentals, not just generating code.

This isn’t about earning credentials or paying dues. It’s about recognising that building good software requires real knowledge, careful judgment, and respect for complexity. AI makes the learning faster and more accessible, but it doesn’t make the learning optional.

If you’re stepping into building software with AI tools, stay curious about the fundamentals. Not because you need credentials, but because understanding why things work the way they do will make you better at evaluating solutions and making decisions.

When the AI generates a database query, ask yourself: what happens if this table has a million rows? When it handles user input, wonder: what if someone types malicious code? When it stores data, consider: who should be able to access this? When it makes an API call, think: what happens if this service is down?

These aren’t trick questions requiring advanced degrees. They’re the kind of thinking that leads you to learn about indexing, input validation, access control, and error handling. Learn them in context, as you encounter them, from documentation and from asking people who know more than you do.

Good practice is still crucial. A well-engineered system that delivers good user experience with performance, reliability, and security still matters enormously. But good practice is learnable. It’s not a secret only revealed to those with the right credentials.

We’re heading toward a world where domain experts can prototype and build solutions to their own problems. Where the conversation with technical experts becomes about design decisions and trade-offs, not translation. Where good engineering practices can be learned in context, as you’re actually building. Where “proper developer” stops being a binary credential and becomes a spectrum of deepening expertise.

The role definitions we’ve held onto - “coder,” “developer,” “engineer,” “technical,” “non-technical” - are now more arbitrary than we would have previously admitted. They reflected how we organised work in a world where implementation was expensive and required specialised knowledge. In her presentation on the ThoughtWorks conference, Annie used the term “Producer”. One attendee observed that her original role in digital some 30 years ago was “Producer”.

That world is changing fast.

If you understand a problem deeply and can articulate what a solution needs to do, you’re already thinking like a developer. The rest is learnable. Start building, stay curious about why things work the way they do, ask questions about the choices being made, and don’t wait for permission from gatekeepers who are guarding a door that was always unlocked.

The question isn’t “are you a real coder?” The question is: can you build software that solves real problems? If you’re willing to learn as you go, the answer is yes.