The right place to draw the line

The design engineer is having a moment. Atlassian recently published a piece articulating their version of the role, which they call the Design Technologist, someone who sits between design and engineering, builds real interactive prototypes rather than static mockups, stewards the token layer, and helps translate design intent into code for the engineering team. It is a more precise and more useful framing than the decade-old "designers should code" discourse it is quietly replacing. The demand, as Atlassian puts it, is not about replacing designers or engineers, but bridging the gap between them.

That framing represents real progress. But even this more refined version leaves a question unanswered. Where, specifically, should the design engineer actually be contributing? The boundary matters more than the concept. Get it wrong and you have a designer who is a net cost to the engineering team, regardless of how well they code.

A more defensible position is this. Designers should contribute to the design system codebase, and they should not contribute to feature delivery repos. The boundary is not a compromise. It is the actual argument.

The version of the discourse that argues designers need to "understand" code is usually a call for empathy rather than proficiency. The version that argues designers should commit to production repos tends to produce either resentment among engineers or designers who spend their best hours debugging TypeScript. Neither outcome improves the product. The design engineer concept is an improvement on both of those positions, but it still needs the boundary to do useful work.

At Woolworths, the design team started without any repo access at all. The early engineering cohort was backend-oriented; front-end work was undervalued, and the idea of designers contributing to any part of the codebase would have been fringe. The shift came through a specific hire, a full-stack developer with strong front-end experience, assigned dedicated time to build out the design system. That relationship, more than any tool or access decision, was what made design-side contribution possible.

Getting into GitHub and VS Code opened up a specific surface, mapping design tokens onto PrimeNG components, maintaining tokens across light and dark modes, and eventually making direct changes to the design system without a full ticket-and-sprint cycle. The changes were reviewed by the design system developer before they went anywhere. That review process is load-bearing. It is not a safety net for bad code; it is the mechanism that keeps the work inside the design system boundary and out of places where it does not belong.

The AI tooling shift is real and it matters here. Copilot and Gemini made it materially easier to contribute at this layer, because design system work at the token and component property level is a tractable problem for code generation. You know what a token should map to. You know what the component API should accept. The AI is filling in syntax and pattern, not architecture. That is different from feature delivery, where the unknowns are usually structural and where generated code without deep context of the repo creates more problems than it solves. Two years ago the AI argument was weaker; right now it is genuinely supporting a different kind of contribution than it was.

This is also where the Atlassian framing holds up specifically well. Their DTs build prototypes to get teams from "I think this will work" to "I know this is right" before it is expensive to find out otherwise. That is precisely the kind of work that sits at the design system layer, testing component behaviour, validating token decisions, exposing edge cases in interaction patterns before they reach feature development. The design system is the right surface for it. Feature delivery repos are not.

The downstream effects compound in useful directions. Working in the design system codebase built enough fluency to produce a coded prototype for a vendor engagement, using the design system components directly. That prototype exposed requirements that flat Figma frames had not. It also changed the register of conversations with engineers, not because designers suddenly became engineers, but because having opened a few files, mapped a few tokens, and read error messages in the console rather than being screened from them, there was enough shared vocabulary to discuss an implementation problem rather than describe it.

The case for staying out of feature delivery repos does not rest on capability. A designer fluent enough to contribute to the design system can probably make a small change in a feature repo. The case rests on economics and blast radius. Feature repos carry business logic, state management, accessibility constraints at runtime, and integration surface with systems the designer has not touched. A well-intentioned change in the wrong place carries higher review cost, higher risk of regression, and a different kind of accountability than the design system warrants. The design system is the layer where the designer's perspective is most relevant; the decisions being made there are design decisions expressed in code, not engineering decisions that happen to have design consequences. That distinction does not hold at the feature layer.

The design engineer concept is a genuine step forward in how the industry thinks about the boundary between design and engineering. The next step is specifying where that engineer should actually be working. Not "designers should code" as a general orientation toward craft, but designers contributing to the layer where design decisions live in code, with review, with a real relationship, and with the good sense to stay out of the feature repos. The AI tooling context has lowered the floor, but it has not changed the logic of the boundary. If anything, it makes the boundary more important to state clearly, because the tools now make it easier to end up somewhere you should not be.