Synthetic developer, the solo designer’s best friend?

Ever tried scoping a real project with AI to simulate developers expertise? I did. Here are the results.

If you’re a solo designer in the team, then you probably felt… well, lonely.

At least I did, sometimes. Not that my developers colleagues weren’t helpful. But in a fast paced environment, where delivery is key and discovery is secondary, developers aren’t always available.

During my thesis research about AIs’ impact on dev/designer collaboration, I interviewed designers that had the same experience. That, or they worked in an environment where developers and designers never interacted: everything went through the Product manager.

That’s when I decided to test an idea that wandered in my head for some time: the synthetic developer.

From synthetic user to synthetic dev

The first time I heard about a synthetic user was through a classmate’s article. The idea was simple: instead of interviewing real people, you generate a user with AI and run research on them.

This simple presentation got me to think: If we can fake users feedbacks, could we fake colleagues expertise too? After some research, I’ve stumbled across very interesting perspectives on synthetic colleagues, going as far as creating a “synthetic department”.

Fast forward a few months. I was thrown into a project mid-flight. No kickoff, no discovery, no user research. Only an oral briefing, a vague description of the client’s expectations, and the pressure to deliver.

Normally, this is when I would turn to developers, to help me clarify what’s feasible, what’s risky, what needs prioritizing. But I used this opportunity to test the value of AI as a substitute: I tried working with a synthetic expert, and created Tim.

And that’s when you may be wondering: Is this designer suggesting we replace developers with AI? The answer is no. What I wanted to understand was whether a LLM could replicate the kind of reasoning developers use when making trade-offs and spotting risks. Not to take their place, but to help designers explore technical constraints when no human counterpart is immediately available.

The experiment: building a synthetic developer

Tim was a developer persona powered by ChatGPT, my “synthetic dev”. I chose ChatGPT because:

• It has unlimited use (unlike Claude) which was important at the time for my thesis research.
• It’s the designers most used LLM, according to Designlab’s State of AI in UX and Product Design.

Tim’s job was to act as if he were my colleague, ready to discuss scenarios, constraints, and the structure of the interface.

I gave Tim a detailed persona (experience level, tech stack expertise, communication style) blending the experience of my two colleagues: one senior engineer, one junior developer. I fed him the project brief, including tech stack, user roles, core CRUD features, and industry-specific constraints. Then I ran a structured design discussion, asking him to help me on:

• Generation of typical use scenarios for the 3 main screens detailed in the briefing
• Specific technical constraints depending on the sector the product will be used
• Hypothetical zoning of screens

Later, I ran the exact same exercise with the two actual developers from my team. Same questions, same format, same project brief.

The contrast was striking.

What the synthetic dev got right (and wrong)

Tim excelled at certain tasks. He helped me structure three Jobs To Be Done when I was struggling to articulate user needs clearly. He proposed a data model that anticipated change logs requirements I hadn’t considered (example 1, see image below). He explained complex technical concepts in designer-friendly language. And he was instantly available. But his limitations became clear when context mattered most.

He also sounded too generic, too polished, too “ChatGPT” (example 2). At times, the responses felt more like “helpful AI assistant” than “Tim the developer”… Especially when offering solutions rather than asking clarifying questions. The persona worked best when I explicitly framed questions as developer-to-designer exchanges, but would drift toward generic helpfulness otherwise.

More critically, Tim occasionally hallucinated, most notably when he invented industry-specific project experience to justify his choices about the workflows (example 3). But the real issue wasn’t frequent fabrication; it was premature consensus. Tim would propose technically sound solutions without first questioning whether the underlying problem existed.

He was working from general developer knowledge, not our team’s knowledge.

What real developers brought to the table

The real developers brought something Tim couldn’t: skeptical curiosity. Where Tim would propose solutions, they’d ask “But have you checked with the client if they actually work this way?” Where Tim suggested optimization patterns, they’d question “Do we even have that problem yet?”

Users with multiple roles, need of in-app authentication for some features, further development of the product… They pointed out infrastructure context, security concerns, feasibility trade-offs, things Tim simply couldn’t know. They also brought institutional knowledge.

At times, they went too deep, drifting into implementation details that weren’t immediately relevant, but that richness was what anchored the project in reality.

The conversation didn’t end with answers. It led to relationship-building. We created a dedicated Slack channel for ongoing design-dev exchanges. The collaboration deepened beyond that single project.

The real insight: synthetic as scaffolding, not structure

What this test taught me about the nature of collaboration itself: AI can help us simulate collaboration, but not replace it.

Working with Tim showed me the potential of synthetic colleagues as preparation tools. They can:

• Help structure thinking before human discussions
• Generate first-draft solutions to stress-test
• Provide on-demand expertise when humans aren’t immediately available
• Act as a rehearsal tool for complex conversations
• Help us cover any angles we may have missed

But they also:

• Miss context-specific constraints
• Hallucinate with confidence
• Can’t build relationships
• Don’t challenge assumptions the way humans do
• Lack the messiness that leads to breakthrough insights

The real developers gave me more than expertise. They gave me relationship, institutional knowledge, and collaborative momentum that extended far beyond our initial conversation.

How to use synthetic developers effectively

It’s important to take into consideration that my observations are based on this one test, as I couldn’t replicate it with another LLM or for another project (yet).

Nonetheless, based on my experiment and broader research, here’s my recommendation: adopt a hybrid approach that leverages AI preparation while protecting human collaboration.

This framework has three interconnected phases:

Phase 1: preparation with AI

Use synthetic developers as thinking partners to structure your approach before human discussions. The biggest limitation? They don’t know what they don’t know. Tim’s hallucinations mostly came from lack of context.

To make this phase effective:

• Document your project context exhaustively (industry, tech stack, existing architecture)
• Ask a real developer to help you craft that context, they’ll know what details matter
• Use AI to generate edge case scenarios, identify potential constraints, draft initial taxonomies
• Formalize concepts you haven’t articulated clearly (in my experiment, Tim helped me structure Jobs To Be Done that became foundation for richer conversations later)

Making AI useful requires human collaboration upfront. Treat AI outputs as conversation starters that help you ask better questions.

Phase 2: expert validation

Always validate and enrich AI outputs with real humans. My test showed that Tim could provide useful initial framing, but the real developers brought context, nuance, and ideas no LLM could generate.

This isn’t about AI replacing 30 minutes of developer time. It’s about making those 30 minutes exponentially more valuable by arriving prepared with structured questions and preliminary solutions to stress-test.

Expert validation teaches you how to improve your synthetic colleague. What did the AI miss? What context mattered most? Use these insights to refine your prompts and evolve your persona. The goal isn’t perfection, it’s a framework that improves and adapts with each project.

Phase 3: collaborative momentum

Here’s the critical part: the ease of AI creates a dangerous temptation. When you can get “good enough” answers instantly, it’s easy to skip the messier, slower human conversation. Especially under deadline pressure.

That shortcut erodes exactly what makes collaboration valuable: relationship-building, institutional knowledge transfer, creative friction that leads to breakthrough insights.

Set a rule for yourself: If you use AI for preliminary exploration, commit to following up with humans. Even if AI “worked”.

The Slack channel that emerged from my real developer conversations became infrastructure for future collaboration and documentation of our progress and choices. No amount of synthetic dev efficiency could create that.

Final thought

Back to my main question: is a synthetic dev the solo designer’s best friend?

Well, not really. The designer’s best friends are still the colleagues who bring the expertise she or he lacks. But the synthetic dev can help bridge the gap: a facilitator to learn the developers’ language, a thinking partner to explore ideas. This experiment proved to me that synthetic actors (devs, users, PMs) aren’t about replacing, but about filling the gaps where communication or collaboration become harder.

Still, scaffolding isn’t a house. A synthetic dev isn’t a colleague.

The goal was never to replace developers, but to explore how much of their reasoning AI can truly emulate. The future of design won’t be about choosing between humans and AI. It will be about weaving them together, making the most of what’s fast and scalable without losing what’s human and irreplaceable.

What about you? Do you use LLMs to extend your team’s skills or simulate an unavailable colleague?

This article is part of my thesis research on AI’s impact on product team collaboration. Read the full research article.

Synthetic developer, the solo designer’s best friend? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post first appeared on Read More