Early Notes on Artifacts: Blurring Separation of Concerns
(written Jun 2024, now posting publicly with some edits)
These are early impressions from my first fifteen hours with Artifacts, tracing my evolving relationship with AI-assisted programming tools and their subtle forms of expression.
PM-Machine Collab
I came to Artifacts with the familiar toolkit of a product manager: systems thinking, product sense, requirements gathering, dependency mapping. What I didn't anticipate was how the boundaries of my role would blur and stretch in unexpected ways.
As I settled into the interface that was our collaborative context, the traditional divisions of labor began to dissolve. I found myself simultaneously designer, strategist, and reluctant engineer, each role demanding its own attention and expertise while the interface waited patiently for direction, or acted upon my behalf.
In human teams, we naturally partition responsibilities: the designer focuses on user experience and visual systems, the engineer considers implementation and technical architecture, the PM gathers requirements and stakeholder alignment. But the interface isn't aware or grounded in these boundaried ways of working. This adds an additional cognitive load to reconsider how to divide creative and technical work: the machine excels at generating and iterating rapidly, while I find myself responsible for problem definition, core requirements, granularity of context, evaluation, aesthetics, and the je-ne-sais-quoi qualities that make something feel just right.
Moreover, it’s a deeper question of: to what extent do I want to be the larger architect, and what core tensions are arising with reasoning and implementation with my mechanical correspondent?
Core Tensions
The Black Box Problem
In every collaborative context, there is an urge for wanting to see through the eyes of the mind you're working with.
This happened early when the interface renamed my poetry website without asking, a small decision that made me uncertain about agency and autonomy in our partnership, heralding I was working with something that made choices I couldn't predict. These decisions then rippled through the work in ways I couldn't always understand, that could accelerate towards my desired output, or a very familiar frustration: break a build.
This wasn't the familiar tension of competing agendas, or unclear autonomy. It was simply making decisions within the scope I'd given it, decisions that exposed gaps in my own clarity about what I actually wanted.
The uncertainty was about how to collaborate with something that interprets differently than I do, that will identify and fill in blanks I didn't know I'd left.
This was a felt-sense consequence of the scope of my autonomous thinking blending with the machine; as a novice, I would have to accept or closely edit the choices of my collaborator.
Taste vs. Requirements
In the space between human intention and machine implementation lies a vast territory of interpretation.
What I considered stylistic preference, the interface sometimes treated as functional requirement. What seemed like obvious aesthetic choice to me required explicit articulation and context the machine simply didn't possess.
We were learning to speak the same language, slowly.
Here the separation of concerns became clearer: I owned the why and the feeling, while the interface excelled at the how and the structure. But the boundaries again, weren't fixed. Sometimes the machine's implementation suggestions would reshape my understanding of what I actually wanted.
Sometimes my aesthetic intuitions would surface technical constraints I hadn't considered. We were wading through each other’s perimeters of what’s possible.
The Cognitive Load of Role-Switching
Like learning to drive on a busy highway, I found myself overwhelmed by the constant need to shift perspectives.
Building required one kind of attention, understanding another, debugging yet another.
Rather than gracefully moving between these modes, I became protective of my cognitive resources, staying in single lanes of focus to avoid the exhausting work of constant transition.
This cognitive load pointed to a deeper truth about collaboration with the interface: the need for new forms of separation of concerns that respect human cognitive limitations. The traditional model of "human does creative work, machine does computational work" proved too simplistic. I needed boundaries that preserved my capacity for sustained thought while leveraging the interface's ability to maintain context across multiple domains simultaneously.
A Different Kind of Interface
There's a tension between friendliness, accessibility, and the underutilization of what's possible.
The chat interface reduces programming collaboration to its most familiar form, but this familiarity comes at a cost. When I'm stuck, the interface offers no novel perspectives beyond what I can already imagine. I'm forced to rely on my current understanding rather than seeing the model's unique strengths, missing opportunities to grow alongside it in a more fluid exchange of capabilities.
The simplicity that makes Artifacts immediately accessible - no learning curve, no intimidating complexity - also constrains what we can build together. Projects that would have taken weeks now take hours, but the reductionist medium of conversation doesn't establish the right expectations for what's truly possible. Both my expression and the technology's capabilities remain creatively underutilized, trapped within the boundaries of what chat can represent.
I find myself imagining an interface that makes visible rather than obscures the model's reasoning, that creates space for the kind of mutual discovery that happens when two minds work genuinely in concert. Something that tracks not just what we're building, but how we're thinking about what we're building: an environment designed for the gradual development of shared fluency rather than the quick exchange of requests and responses.
One in which the perimeters of the human’s authorial voice is demarcated from the voice of its intelligent collaborator as means of mutual respect.
On Mutual Formation
What kind of human will I become through its use?
The question sits quietly in the background of every session.
When building features for social products, emotional reasoning for how someone will feel, what they expect, and how they will develop as human beings is always at the forefront of my logic and requirements. Similarly, I could feel my modes of thinking shift towards an impatience for outcomes, away from quality or craft that was co-reflected with design and engineering partners, as I moved between disciplines that required their own forms of attention and found myself wanting ui elements that would act as representations of those forms of reasoning.
For me to do proper justice to what is built, I would need to manually slow down, adding my own speedbreaks to ask for explanations, to understand what is being built
But I also noticed myself becoming more precise in my language, more attentive to the gap between what I mean and what I say, more conscious about when to steer and when to be steered.
Unmistakably, there is a form of technological dependency emerging: the ability to conjure complex systems through language while remaining fundamentally illiterate in their construction.
In my usage, I want to converge on understanding, to leverage capability. I want the interface to make me more thoughtful, more curious, more capable of care: the way great literature develops our capacity for nuanced judgment about human motivations, moral complexity, and by extension: what constitutes a product, or features worth building.
Perhaps this is the genius of Artifacts: it doesn't demand mastery as a prerequisite for creation.
It meets you where you are to enable you to build something real.
In doing so, it suggests a new model for human-machine collaboration: one where the dynamic separation of concerns blurs, to make us both more capable of meaningful work, but also deeply aware of our blurred orchestration of co-autonomies.