Design Engineering, All the Way to Prod

This semester I shipped a piece of software that is now live across my company, published an essay claiming that this hybrid shape of work is where the profession is heading, and then read 95 job postings to find out which of my skills the role actually wants and whether it exists in the country I live in. Several of the answers went against me, including two I had already told people. I also let the one course whose whole subject is deliberate self-development be the one I handed in late.

All the way to prod, and what it cost

For two years I have been circling the same question: am I a designer who codes or an engineer with taste, and does the answer matter. This semester the question stopped being interesting, because I got to do the whole job and see what happened. I wrote the product specification, designed the interface, built the backend and the frontend, built an MCP server so AI agents could use the product as a first-class client, wired up single sign-on, commissioned a security review and acted on it, cut the release, and stood in front of the company to present it. In February I had never built an MCP server, never implemented OAuth 2.1 with PKCE, never wired an app to a real corporate identity tenant, and had only ever been on the receiving end of a security review rather than the person who orders one. Those four are the honest delta of the semester - and notice that three of them are backend and identity, not design. I come back to that at the end.

What I could not do in February

The four first-times above are the headline, but they are not the part that changed how I work. That

part is less photogenic: I stopped being a person who writes an application and became a person who

argues for the infrastructure it runs on, decides what it costs, and unblocks other people's

deployments. Concretely, and none of this existed in my February self.

1. Sizing infrastructure against its running cost, not its ceiling: my first draft of an

   infrastructure request asked for a dedicated cluster - three workers, control plane, a couple of

   hundred gigabytes of storage. I talked myself back down to a namespace on the shared cluster with

   a quota, because a dedicated cluster only buys cluster-admin freedom and charges you your own

   ingress, monitoring and upgrades for it. Then I filled the holes that would have made the first

   version fail anyway: registry pull access, egress, the ingress class.

2. Procurement decided on verified facts rather than the marketing page: before asking for a

   paid hosting tier I checked what the tier actually includes, found that the shared-password gate

   everyone assumes is a separate add-on, that without it every viewer needs their own account, and

   that the platform's own database had migrated to a third party eighteen months earlier. The

   request went in for the cheapest configuration that met a confidentiality requirement, with the

   expensive option named as a future one.

3. Designing how work gets recorded, not just doing it: I set up the issue hierarchy our

   infrastructure work now lives in - a container epic, a task per application, subtasks for the

   technical steps - after finding out the obvious structure could not parent the tasks. Small, dull,

   and the reason the next deployment does not start as a flat pile of tickets.

4. Mail deliverability and DNS as a product problem: getting a colleague's dashboard live meant

   a sender subdomain with its DKIM, SPF and MX records, two hostnames for production and staging, a

   certificate-authority pitfall that would have broken issuance, and a mail-flow check against the

   corporate quarantine. I also wrote a "what we are not asking for" section into the request, which

   is the part that kept the scope from doubling.

5. Owning a product at company scale, end to end: specification, architecture, both halves of

   the code, the agent interface, identity, a commissioned security review, release, announcement and

   a company-wide demo. Not one link of that chain was mine a year ago, and the ones I found hardest

   were the ones with other people in them.

What the role actually asks for

Shipping one product is one proof, not a profile. So I went looking for what separates this work from the two jobs it sits between, using the postings I collected in a day: 95 rows, 89 unique after deduplication, of which 13 rows require both halves and 41 are plain design roles. The ratios below are over those raw rows, and they carry a confound I cannot remove: seven of the thirteen hybrid rows are a curated foreign benchmark, while most of the designer rows are Czech. Employer type is doing some of the work that looks like role type.

Two things I expected to find did not survive the arithmetic.

Taste is not the answer on its own. It is asked for on 9 of the 13 hybrid rows, and on 14 of the 41 designer rows - so a third of plain design jobs want it too. It is asked for more often on the hybrid side, not less; what it cannot be is the thing that distinguishes the job, because a requirement a third of designers already meet is not an edge. Anyone whose pitch stops at "a designer with taste who can also code" has named something both jobs ask for.

AI fluency is asked of everybody now. 6 of the 13 hybrid rows against 15 of the 41 designer rows - about 46 per cent versus 37 per cent, which is close, and closer than the reversal I first thought I had found. I had assumed AI tooling would be what separated the two jobs. It is table stakes on both sides, which is a duller and more useful finding.

What actually separates the role is where accountability lands. A designer is judged on an approved file; a design engineer is judged on the running artefact. Vercel says it on its design-engineering principles page - shape the product, design the interface, ship the code - and the cleanest evidence I found is not a design-engineer posting at all, but a designer posting at a company that employs them: "First and foremost, this is a visual design role… You'll work shoulder-to-shoulder with design engineers who turn design into production code… coding is never a requirement."

Against a frontend developer the difference is one word: authorship. The most portable test is grammatical. Four frontend postings on the Czech market, from employers on three continents, share one sentence shape: collaborate with the UX designer to implement, work from Figma designs and implement against design tokens, work together with the designer (in Czech), translate 3D design requirements. The design decision arrives from outside. Stripe had both roles open on the same day: the design engineer needs "a portfolio of design work and frontend code"; the full-stack engineer needs "3+ years of experience as a backend engineer", and that posting mentions design, Figma, typography and motion exactly zero times.

Six things the foreign postings ask for that are rare or absent on the Czech side of my sample: two portfolios rather than one; a named production stack the designer commits into; design-to-code plumbing as a duty, spelled out in one posting as authoring Figma Code Connect mappings "so Figma components link cleanly to their coded counterparts for engineers and agents alike"; a published band priced like senior engineering; a high seniority floor with no junior track; and the discipline existing as a named org function with a manager and a written boundary.

The skills I can actually evidence

Against that standard, here is what this semester left me with, one proof each.

1. Designing interaction for a reader that is not human: the instruction text and 15 hand-written tool schemas my MCP server hands an agent are a manual of conduct, not API reference - retrieval strategy, repair strategy, refusal semantics, and the rule that an agent hits the same visibility and rate limits the human interface does. Not one of the 41 designer postings asks anyone to design for a non-human consumer.

2. Accessibility as a decision the design depends on, turned into a build failure: a brand accent that cannot carry text at the contrast floor, two darker tokens derived for text while the accent stayed decorative, and then a linter that fails the build if the decorative token is ever used for text again. Designers are asked for accessibility awareness; authoring the check that stops the regression from coming back is the other half of it.

3. Review discipline over AI output: a 20-item pre-flight checklist distilled from one reviewer's history, plus a ledger of named reproducible failure classes - including the entry I wrote against myself, where my own AI review read one code path and confidently concluded the round-trip was fine. The tools are table stakes; being accountable for what they emit is not.

4. Knowing which layer a problem belongs to: I built a keep-alive mechanism for long-lived agent streams with a real concurrency test matrix, then upgraded the library myself and deleted about six hundred lines including the tests I was proud of, because the fix belonged one layer down.

5. Design tokens and dynamic theming in a shipped mobile product: earlier in the year, on a different codebase and a different stack, a token system with runtime theme switching, plus the debugging that comes with it - a race between a query and the action handler it depended on, and a rendering difference between web and native that only shows up on device. Different employer, different half of the year, and the reason the list above is not all one product.

6. Building the structure instead of remembering: a logging system I built to record my own work failed quietly for two and a half months, because logging was always the last step of a task and the last step is the one that gets dropped. The fix moved the decision out of a model's judgment and into a runtime hook.

7. An idempotent round-trip where the check cannot drift from the thing it checks: one rendering function with two consumers - the puller writes its output to disk, the checker compares its output against disk - so "no drift" means exactly "a pull right now would change nothing". It is small enough to read in full, which is why it is the portfolio piece with no NDA to negotiate - and if you do read it, you will also find no test runner, no linter config, an agents/ directory declared in the layout and empty, and three post folders that were never committed, including the one holding this text. The system works and the habit did not fully transfer, which is its own finding about structure.

8. Shipping to strangers, not to a demo: a macOS app taken from a build that ran on one machine to a notarized, Developer ID signed, self-updating release a stranger can download and open without a Gatekeeper warning. Certificates, entitlements, the update channel and the distribution paperwork are the half of "ship the code" that no design course covers, and it is publicly inspectable, which most of the list above is not.

9. A full-stack product built by orchestrating agents, in five days: a hosted markdown reviewer - upload a file, share a link, collect inline comments from people who do not use git, download the file with the feedback embedded - built on Next.js, TypeScript, Supabase and Vercel with a team of thirteen AI agents. It is running in public, which makes it the second proof anyone can open rather than take on trust.

Does the role exist in Czechia?

Five channels, all public and non-logged-in: a near-census of one Czech board via its sitemap and public API, LinkedIn's guest endpoint, full-text queries on the largest mainstream portal, 35 company career pages through their own ATS APIs, and a curated foreign benchmark for contrast. 95 rows collected on 21 August 2026, 89 unique. Classified strictly: both halves as hard requirements, one side dominant, or one-sided.

The limits first, because they decide what the findings can mean. One day, in a weak Czech hiring month. Login-gated boards were not scraped, and one channel yielded nothing at all, so every count is a floor. "Not found" throughout means "not found in a public sample of 89 postings collected on 21 August 2026", never "does not exist". And the base rate matters more than any single zero: the board I could enumerate carries only 19 design or frontend postings in total, so even at genuine low-frequency use, seeing zero has roughly a 38 per cent chance.

The term is not in the vocabulary. On that enumerable board, "design engineer" appears zero times across all 444 public postings - not in a title, not in a body - and the same holds for design technologist, UI engineer, design systems engineer, frontend designer and produktový designér. Read with the base rate above, that is a strong absence within one startup-scene board and a hint about vocabulary, not a measurement of a market.

The English title is occupied by a different profession. Search the Czech market for it and you get machine building: the two postings I read in full under that bare title were a 3D CAD role in automotive and an infrastructure role doing structured cabling in Revit. One advert translates itself in place: Design Engineer | Konstruktér | Statik, where konstruktér is the Czech word for a mechanical draughtsman and statik a structural engineer. The software sense does appear on LinkedIn CZ, but in this sample only in remote listings from non-Czech employers. So it is a search collision rather than an absence: candidates and employers do not meet on that word.

One posting asked for the whole role, and had to invent a title for it. Fakturoid advertised a role it could only describe as a split - "We are looking for a lead: 50 % UX/UI designer, 50 % HTML/CSS frontend developer" - and it pre-emptively refuses both of the market's usual compromises: "We are not looking for a pure UX/UI designer who occasionally reaches into the code. Nor are we looking for a frontend developer who merely handles design-to-code well." It names design-system-in-code work, names its stack, and publishes a band. And it has no title - the market described the role by percentage split. That single detail is the whole study in miniature.

Usually the two halves are advertised as two different jobs. One bank's Prague office ran two UI Engineer postings dedicated to a design system - React, TypeScript, design tokens, Style Dictionary, Token Studio, Storybook, WCAG - with no design-craft requirement at all, while designers own the same problem elsewhere with code appearing as "technical acumen" or a bonus. Three caveats travel with that: the engineering-side pattern rests on one employer, one of the designer-side rows is a remote EMEA employer rather than a Czech one, and one classification was read differently by two independent readers.

The work has local names, just not this one. It arrives as kodér, the Czech word for a front-end coder, in the agency lineage, where design sensibility is required and UX is demoted to the bonus block; as Product Builder, the 2026 AI-native generalist; as Product Engineer, the engineering half with a taste clause; as UI Engineer, the code half of a design system; and as a UX title with a front-end overlap buried in the body, always listed as "an advantage" rather than a requirement. Structural corroboration: the largest Czech board has no occupational category for the hybrid at all.

And nobody has named it in Czech. A documented search of Czech design and front-end media found no article, talk or podcast episode that defines design engineering in the software sense. The nearest local definition is a decade old and uses a different word - Martin Michálek, writing about the frontend designér: "a person who can design a user interface and at the same time prototype or implement it." He adds that he jokes there are only two such people in the country, himself and one named colleague, though he recently saw an advert looking for a third. That was 2016.

Counter-evidence I am not going to hide

The discipline is better documented than it is staffed. Of thirteen companies picked because they are known for design engineering, exactly one had an open design-engineer-titled role on 21 August. Vercel, which wrote the canonical blog post, publishes a principles page and runs a team named after it, had zero such openings among 83 vacancies. Linear's is a 404, Rive's was archived in November 2025. Scanning roughly 30 further boards produced three live specimens.

It may be consolidation rather than growth. SignalFire's State of Talent 2026 reports, against a 2019 baseline, "Design: Down 48% at Tech Majors and down 22% at startups" and that "the share of front-end engineer roles is down ~25%, the steepest decline among engineering specialties", and recommends founders "consolidate front end and product design: merge front-end implementation, design, and product prototyping into cross-functional 'product builder' roles". Its "Tech Majors" is its own set of twelve large US companies with no Czech stratum, so it cannot explain a Czech naming pattern - but if this is consolidation, design engineering is not a new layer on two healthy markets. It is the surviving shape of two shrinking ones.

And a credible argument says the merger is wrong. Cagan and Baxley argue that product management and design are distinct roles AI makes "even more essential" rather than dissolving. Their target is a different merger than mine, so it is adjacent counter-evidence - and I would rather cite it than leave it out.

Three things I cannot evidence

The same audit found gaps, and these three are worth saying out loud.

The design half of this role is my thinner half, and this semester ran the wrong way. Three of my four first-times were backend and identity. Meanwhile the authorship deltas - production work in Figma, a design-to-code contract, a visual language originated from nothing - have the weakest evidence I have. If the role is defined by originating the interface rather than implementing it, I have been strengthening the wrong side.

And I have never been the gate on another person's code. I am reviewed-by, not reviewer-of, and nothing in my records shows me reviewing unprompted. The ladder in this role tops out at owning a surface until you can be the standard for someone else's.

Two more, and these are the ones a hiring reader prices highest. Runtime performance is a blank: it is a hard requirement in 5 of the 13 hybrid postings I collected, and I have no profile, no budget and no measurement anywhere in a year of work. And almost everything above is my own account of my own work - no performance review, no external reference, no usage metric, and the largest thing I built is internal-only behind single sign-on, so nobody outside the company can open it.

How I actually learned it

Two strategies did the work, and naming them matters more than listing outputs.

The first is deliberate practice against my own recurring errors. Rather than treat each review comment as a one-off, I distilled one colleague's past findings into a pre-flight checklist and ran it before opening a pull request. Over the semester the same classes of finding stopped recurring, and by the last batch the review came back with no suggestions. The generalisation is that my errors cluster, so the leverage is in the class rather than the instance.

The second is adversarial review with one skeptic per finding. I started using it on code in June and ended up using it on my own research in August. It changes what I produce, because I now write knowing something will try to break each claim - and it produced the most uncomfortable result of the semester, which is exactly the point.

The clearest thing I can point at as transfer is one principle moving between unrelated fields. In the service-design course, every research finding ended up tagged with its evidence status - firsthand, secondhand, inferred - and that did not come from me policing myself: a ten-agent adversarial review caught my own tags contradicting each other across three artefacts. I kept the tags. In August I applied the same principle to a corpus of job postings, where every quotation carries a verified flag and absences are phrased as absences from a sample with its date. The abstracted principle is that epistemic status is a property of a finding, not a footnote about it. Applying it cost me six rewritten headline claims and my most quotable section, which is what transfer looks like when it is real rather than asserted: it takes something away.

Working with other people, and what it cost

Everything above reads as one person doing everything, which is how I wrote the goal and also where it is blind. A fair part of the semester went the other way: getting other people to work differently. I built and ran an AI training session for an internal compliance team - people whose job is regulatory reporting, not software - which meant researching what they actually do all day before writing a line of it. I wrote the follow-up material for two engineering bootcamp cohorts in two countries. I designed the feedback form an internal enablement programme uses to collect its own reflections, which is a strange thing to be doing in the same semester I was supposed to be writing one. And colleagues came one at a time: how do I connect my assistant to our documentation, how do we stop scanning tool adoption reactively and start asking teams directly. Those one-to-one requests were the part of the semester I enjoyed most, and I did not expect that when it started.

On feedback in the other direction I should be precise about which half I am good at. Receiving it went well. Giving it is the weaker half: I review other people's work when asked rather than by habit, and nothing in my records shows me doing it unprompted.

What it cost, in the words I wrote for another course rather than reconstructed now: the ceiling moved. Nobody expects me to be active for fewer hours; they expect a bigger output in the same time. The pressure was not hours, it was that the expected size of an output grew to match the tooling. And when asked which challenge taught me most, my answer was not the one I enjoyed most: prototyping is the part I like, testing and research are what actually moved me.

Progress on My Semester Goals

I set two goals, and I wrote the wording in August from work already done rather than setting it in March and working towards it. Retro-fitted goals are worth less than planned ones, and that gap turned out to be the semester's real subject.

1. Owning a product end to end: fulfilled, with corrections. A colleague reviewed every pull request I opened and wrote part of the MCP package himself; infrastructure and identity were handled by the people whose job that is; I cut releases and verified them rather than deploying. Calling 27 custom properties a design system would also be overclaiming - it is a themeable token layer with contrast enforced by a lint script.

2. Understanding the role on my own market: fulfilled, and it changed my answer. The study above is the deliverable. The most instructive part was not the data: I commissioned three adversarial passes over my own corpus, each instructed to refute my conclusions, and all six claims came back refuted as worded, two of them in substance, falsified by rows inside my own dataset. My zero was a hint, not a proof.

The route I am choosing is to stop looking for the title and define the role where I already am. My working notes still read "my role: to be filled in - design engineering? frontend? AI tooling?" with an empty line underneath. The one artefact this course asks for was the one I had never written.

Reflections on My Courses

DESB32 Service Design: Mapping Experiences

✨ Thorough, Enriching, Refreshing

The most substantial course of the semester and the one I got the most out of. It also gave me room to experiment with the approach rather than run the method by the book, and a potential new collaboration came out of it, which is not something I expected from a course project. The part I am most glad about is the choice of subject: I deliberately picked something that is not another digital product. After a year spent inside screens, spending a semester on a physical place, its signage and the way people actually move through it was the rest I needed, and it made the service-design methods land differently than they would have on yet another app.

DESB43 Design Management & Leadership MasterClass

✨ Timely, Sharpening, Generative

The source of my hypothesis. Luděk Černocký's keynote gave me the sentence the rest of the semester tested: when output is cheap, judgment becomes expensive. The essay I wrote for this course is the thing the study above then made me verify. The two courses share a subject and I kept the steps deliberately different: the essay is a field-level argument from public sources, this is a personal evidence base plus primary market data collected against my own claim. The proof that the steps differed is that this produced four corrections to that essay.

DESB41 Produktové myšlení (Product Thinking)

✨ Structured, Practical, Underrated

Spot on for where I actually am. Problem statements, customer mapping, telling the user apart from the decision maker and the payer - and above all the product requirement document, which happens to be the live topic in several of the collaborations I am in right now. The specification I wrote in May opens with a problem statement that names who has the problem and what it costs them, with no solution smuggled into the sentence, and that is the course showing up in my work rather than in my notes.

DESB45 Budoucnost práce (The Future of Work)

✨ Hands-on, Fast, Fragmented

An automation of my own pain point, shipped as a small web product. I missed the live presentation and moved to the asynchronous route, so I built the artefact well and communicated it late.

ISKB82 AI v praxi (AI in Practice)

✨ Uncomfortable, Honest, Necessary

A travel diary where an AI pipeline compresses voice memos and photos into entries in my own voice. I am repeating this course, and it produced the most self-critical thing I wrote all semester - I ran the whole course through Claude Code without once touching Figma, Framer or Word, and also wrote that I am losing a bit of my agency, and that the craft of working with my own hands is starting to slip away from me.

DESB44 Praxe IV (Practice IV)

✨ Distribution, Paperwork, Finished

The half of shipping nobody teaches: getting a macOS app from "runs on my machine" to notarized, Developer ID signed, self-updating and downloadable by a stranger without a Gatekeeper wall. The case study went out in June and the app is still installable from the link in it. It is also the clearest evidence I have that the engineering half of this role is not theoretical.

Conclusion and Next Steps

Underneath all the auditing, I am happy about this, and I want to say that before the caveats. The role becoming more visible is what let me find my direction. I have always felt like I was standing somewhere between design and development, slightly apologetic about being neither, and this title names the place I was already standing in. My competencies are growing on both sides at once, which is not something either of the two separate careers was offering me. And it brought a third thing I did not expect: project management. Deciding what infrastructure to ask for and how to scope the request, designing how the work gets recorded, coordinating with the people who own the systems, unblocking someone else's deployment - none of that is design or code, and all of it turned out to be part of owning a product rather than a task.

I can hold a whole product - its design decisions, its code, its security review, its release - and be answerable for the result. What I could not do until this month was say which parts of that actually distinguish the work, and the audit answered it in a way I did not expect: not the taste, not the tooling, but who originates the decision and who is accountable for the thing that runs. By that measure my engineering half is well evidenced and my authorship half is thin, which is the opposite of the story I would have told in May. Underneath the rest sits one mechanism - I deliver reliably against other people's deadlines and unreliably against my own - and next semester gets structure instead of intent:

1. Write the role definition: fill in the empty line in my own notes, using this study as the evidence base

2. Originate, not only implement: one surface designed from nothing next semester, with the design-to-code contract written down

3. Be the gate once: review someone else's work unprompted, and keep doing it

4. Build a team around the internal product: it has outgrown one person, and the next problem is not technical. Because the work is a fusion of design and development, I drop to a different altitude at every stage - specification, interface, implementation, release - and that is exactly what does not scale by repeating myself. What it needs is a direction set once and held, so the thing stays maintainable with more than one person inside it.

5. Grow the project-management half deliberately: scoping requests, sequencing work, deciding what not to build this quarter and saying so out loud. It arrived as a side effect of owning a product, and I would rather learn it on purpose than keep improvising it.

6. Review my own commitments with someone who is not me: every second Monday, first slot in week two rather than week ten

7. Keep one thing per project made by hand: I write the travel diary myself for a reason, and the reason has not changed

Method and sources

The corpus behind Part III is 95 public job postings collected on 21 August 2026 across five

channels, 89 unique after deduplication, each classified against a fixed rubric with its reason

recorded. Every claim above was attacked by three adversarial passes instructed to refute it, and

all six of my original claims came back refuted as worded. Company names appear where a posting is

quoted and the employer is a matter of public record; my own employer, its products, its clients and

my colleagues are unnamed throughout under NDA.

Every link below was re-fetched and checked on 24 August 2026.

• Vercel, Design Engineering at Vercel, 29 March 2024 — vercel.com/blog/design-engineering-at-vercel. The definition the discipline is usually quoted from; note the original reads "…technical skills. This allows us to…", not the single sentence that circulates.

• Vercel, Design Engineer Principles — vercel.com/design/engineer. Source of "Shape the product, design the interface, ship the code".

• Marty Cagan, The Era of the Product Creator, SVPG, 27 May 2025 — svpg.com/the-era-of-the-product-creator. Single-authored, and later than the vibe-coding moment rather than earlier, which is a correction to my own May essay.

• Marty Cagan & Bob Baxley, Product, Design and AI, SVPG, 24 March 2025 — svpg.com/product-design-and-ai. Counter-evidence: argues the roles stay distinct and AI makes each "even more essential".

• SignalFire, State of Talent Report 2026, 22 June 2026 — signalfire.com/blog/signalfire-state-of-talent-report-2026. Source of the design and front-end declines, measured against a 2019 baseline, and of the recommendation to merge the two into "product builder" roles.

• Martin Michálek, Pracovní pozice kolem frontend kodéřiny a bludy v pracovních inzerátech, 19 June 2016 — vzhurudolu.cz/blog/62-frontend-pozice. The closest thing to a Czech definition of this role, ten years old, under a different name.

• Fakturoid, Hledáme leada: 50 % UX/UI designer, 50 % HTML/CSS frontend developer — startupjobs.cz/nabidka/106829. The one Czech posting in the sample that asked for the whole role.

• Luděk Černocký, Leading Design in a World Where Anyone Can Build, keynote, 25 February 2026 — cernocky.com/masterclass-2026.

Job postings expire. The Stripe, Barclays, Celonis and Better Stack listings quoted above were read

in full on 21 August 2026 and are recorded in the corpus with their text and classification reason;

several have since closed, which is why they are cited by employer and date rather than by link.

AI transparency appendix

Written with heavy AI assistance, consistent with the appendix on my last post. The evidence base was assembled by agents reading my own working logs, repository history and course folders; the market research and the competency audit were collected and then adversarially reviewed by agents. The judgments, the decisions and the account of my own conduct are mine, and every number is traceable to a file.