Claude, the new kid in town
There’s a new kid in town who recently moved into the huge McMansion down the street. Everybody at school gushes over him, but I’m a little unsure. He’s punctual, dropped off in a Volvo SUV, donning a fresh unscuffed pair of Onitsuka Tigers, an uncanny, unidentifiable strut in his gait. They laugh at all his jokes, they vie for an ounce of his attention, they pine for his advice at the intersection of every road block they hit.
His name is Claude.
And I mean yeah, of course, I like him, too. How could you not? Everything you see, standing right there in front of you, seems like the complete package. He’s got everything a kid could ask for; attention, looks, skills, even a cool name. Claude. Claaaauuu-de. If you stare too long, you might even sense a sliver of jealousy start to trickle down your spine. Do I… do I want to be like Claude?
Snap out of it. No, there’s gotta be something off here, a chink in Claude’s otherwise twinkling armor. He seems too perfect. I’m still trying to put a finger on it, but I have a few leads as to why the relationship dynamic with Claude feels so complicated.
Community engineering at Mux
I work at Mux, a devtools (agenttools?) company building products to solve weedy video infrastructure problems at scale. I’m hired as the Staff Community Engineer, a title we’ve landed on over five years of iterations to properly encapsulate the recurring theme in career conversations: how do we describe what you actually do here?
Developer Relations has a lot of different definitions depending on who you ask, but my perspective is really quite simple: I’m here to help you. It’s a broad enough north star to place me under the internal Marketing umbrella, but even that sometimes feels like the lucky curly french fry you find in the bottom of the frozen shoestring bag: yeah, it’s kind of the same thing, but also, can you really compare the two?
Marketing is all about reaching as many people as you can through stories that show the value of what you’re selling. To me, building community is about reaching each individual with personalized attention and leveling them up by plugging them into the network of people and resources that are solving the same problems or have the same goals that they do. That’s kind of it.
You can understand why people feel so polarized about that job title. “What does that even meeeaaan?” you groan. It’s amorphous, without bones. But that flexibility is exactly what’s required to cover the vast ledger of responsibilities that typically lives in this miscellaneous junk drawer of a job.
Who’s going to keep an eye on how developers are struggling or succeeding with our product? Who’s going to make sure there’s a process for updating well-written documentation as the product evolves? Who’s going to help our internal team write about the importance of what they’re working on, or kindle the fire with sparks of ideas influenced from real customer feedback, or get creative with our product and showcase its capabilities, or talk to developers in the real world at conferences or other meetups?
Who’s going to make sure developers know we’re “one of them?” Claude may be a phenom at writing code, but he’s certainly not one of them.
But he is helpful. And, as someone with chronic imposter syndrome who at times convinces myself I’m not a real developer, Claude steps up in a big way.
Everyone wants to be like Claude
Software engineers are smart. Nobody’s doubting that. At the same time, software engineers are human. We can’t know everything; unlike the boundless universe, our retained skills have to stop somewhere. But somehow, Anthropic’s Claude and their underlying models give you hope, a hanging feeling that maybe there isn’t a limit to what we’re capable of.
Software engineers are lucky. We’ve somehow been able to find a profession that both pays well and tickles our brain. Our everyday tasks are things we might have been doing anyway out of sheer satisfaction.
That doesn’t mean being a Software Engineer is wartless, though. It’s that last 20% of the job description, the part where engineers don’t find joy, that causes the most trouble. Engineers often struggle completing tasks like:
- Code review: I think the code I’m about to ship is bug-free, but how can I know for sure? I wish someone would dive in deep and triple-check my work.
- Rubber-ducking: Is there a better way to think about this problem I’m trying to solve? I wish I could ask someone infinite questions about it without feeling like I’m wasting their time.
- Menial writing: How do I communicate to stakeholders what this code actually does and why it’s important to the business? I wish someone would do this for me.
- Content: How do I tell this story in a way that others will find compelling? I wish someone would brainstorm storytelling angles with me.
- Non-engineering tasks: How do I make sure I don’t drop the ball on keeping the project tracker updated? I wish I had an assistant keeping me on the rails.
Claude steps in to fill a huge gap here. He acts like the personal trainer at the gym, spotting engineers on the last few reps of work right before they run out of steam, taking the weight off of engineers’ most uncertain tasks. Claude hears our wishes, swirling in like a summoned genie and freeing us up to do the work that’s actually important.
Wow. I’m starting to understand why everyone’s vying for a seat at Claude’s lunch table in the cafeteria.
Where talking to Claude breaks down
This may come as a huge surprise to you, but programmers have a lot of opinions. It’s what makes them so good at their jobs. It’s also what can make the relationship with Claude somewhat contentious. I confess: we might get a little prickly when work is performed in a way that deviates from our opinions, or what we believe to be the right way.
We formed these opinions over years of strife, struggle, studying, and implementation. We learned the hard way. We built up our perspective by getting in the trenches and digging deep. We dealt with failing unit tests until they turned green. We gained style and experience points from getting the dirt of logic under our fingernails. And truthfully, we enjoyed the process.
Claude does not have a taste of its own (sorry, bud). He wears the latest advertised fashion from the summer trends magazine. Claude is trained on the published artifacts of the general population. That may be a fine place to start when considering a problem to solve, but it also means that Claude will sometimes make decisions that we may not have made.
That’s fine, right? Engineers are great mentors. We are always willing to help a junior grow by describing the changes that they should make and explaining why they should make said changes. There’s a really satisfying unlock that comes with seeing someone under you grow and thrive.
Unfortunately, the bottom has fallen out. We’re not mentoring like we used to anymore. We no longer have the same opportunity to actualize that unlock with beginner programmers. Most of our correcting is now targeted at agents we’re responsible for conducting, watching them make mistakes that we might not have made in the first place.
These kinds of LLM-isms make us frustrated. They make us want to push back in our roller chairs, throw our hands up in the air and chalk it up to inadequate, incapable tooling.
However, in this new shape of software engineering, this is the exact point in the process where we need to step in and reiterate the agentic rule sets that must be adhered to within any given code base. Your opinions, expertise, perspective, and taste are now captured in Markdown deliverables, to be held in a fashion that can be consumed by the new implementer.
That’s a tough pill to swallow. You’re teaching a program. A program that is inadvertently trying to replace you. Understandably, it’s where a lot of engineers start to get a metallic taste in their mouth.
It is a strange type of mentoring, and admittedly does not feel the same as seeing the grin of revelation slide its way onto the face of a passionate newcomer. If you can find a way to bite your tongue and reiterate your rules and beliefs into a manifest that can be understood by future cold agentic sessions, you’ll run into less of these frustrating moments in the work ahead of you.
It’s also easy to go hard in the other direction and fully delegate your decision making to an agent: Are we done, Claude? What should we build next, Claude? What do you make of this user feedback, Claude? Save me, Claude!
The industry has circled around an unofficial term for this phenomenon: becoming a meat proxy. In other words, the behavior of offloading ideas and conversations to the LLM to decide on your behalf. To me, that feels like a form of quitting; we cannot lose our ability to think critically, communicate, make decisions, and stand beside them with reasoning.
I can’t believe I have to write this, but let me remind you, dear reader: thinking is an integral part of being human. It’s our responsibility to exercise those parts of your brain. Just like in the gym, if you don’t use those muscles, they will atrophy. Let Claude be your spotter; don’t stand by and watch Claude lift and get jacked from the sidelines.
We’re dealing with waves of resentment from the ripple of this sudden and jarring displacement. Still, it’s our responsibility to continue to give back to the up-and-coming builder. We must hand down our expertise, teach and share our perspectives, and welcome those new to this industry through a door we hold open—ideally, a door that doesn’t require a paid subscription to enter.
How Claude has changed engineering at Mux
Given this abrupt paradigm shift, we are heavily reevaluating the now-antiquated processes that used to be standard a short time ago. We still keep a tight hold on many of these practices, hesitant to relinquish control to something entirely automated. But every time we set out to explore this newfound terrain, we become flush with novel ideas, often finding that throwing agents into the mix has the potential to be better than the old way ever was.
Take code review. Mux used to require every PR to be approved by a peer employee. Now, we use Bugbot, a product from Cursor, to conduct code reviews on every PR, and we’re considering loosening the merge requirements. If Bugbot’s assessment of the change ends up being low-risk, the proposal is that it can be merged by the author themselves rather than relying on a co-worker’s stamp of approval. This isn’t true for every repo we have, but it’s a comfortable place to dip our toes in the pool. There’s lots of kids already in the deep end with Claude, horseplaying with pool noodles.
Mux may be a bit more careful to adopt unsupervised merges than other companies. We provide critical infrastructure to thousands of customers, where downtime doesn’t just impact us, it impacts them, their brand, and their customers. Our tolerance for risk may be a bit lower than others, but as we continue to carefully assess what we delegate over to AI, we reap the benefits of glow-up engineering practices.
We’ve also had to entirely rethink our definition of developer experience. It’s more likely with each passing day that the primary user of most developer tooling products is an agent, not a human. That means we need to carefully analyze and assess our approach to what constitutes a great experience with our products.
Everything we’ve published for humans over the past decade is now under heavy scrutiny. That includes:
- Written public-facing marketing materials
- Published docs, their structure, and how to access them
- CLI tooling ergonomics
- Code examples, SDKs, and onboarding
- Signup and authentication flow
- Approaches to discoverability and how users find us and our tools
We still have human users that we need to consider, but as this industry morphs into its new shape, we need to ensure we accommodate all forms of the end user.
However, it’s still imperative that you are the primary user of your own product. It’s your responsibility to define your business goals through your product, and assess whether agents can successfully use your product so you can reach those goals. At the end of the day, Mux doesn’t exist if we don’t get paid, so we have to optimize for a friction-free experience for both humans and agents.
The old neighborhood hasn’t changed
What makes for a good agentic experience, and what metrics should you be optimizing for? Turns out it’s not all that different from what we’ve been doing all along: getting the developer to a working solution as quickly and painlessly as possible. The agent may not be human, but its needs are quite similar.
For example, take the Time to Hello World metric—a measurement for how quickly a developer can get to a working integration with your product. How can you improve this metric? In the past, we’d optimize for developer happiness and frustration-free coding. This is still an ideal goal to optimize for, but translated into the machine’s world. Agents who can seamlessly use your product to get to the answer quicker are token efficient, keeping overall costs down for the end user to integrate with Mux, and allowing the agent to drive the integration from concept through execution with full autonomy.
Our reference materials, guides, and prompts must be as accurate as possible; communicating in a clear, concise fashion is crucial.
Agents aren’t always aware that the latest features you’ve shipped exist at all. Marketing still holds true; you must make a concerted effort to help your agent understand your product and provide more avenues than ever to instruct and inform the agent without context bloat.
And you still need to make sure your materials are always up to date. With increased shipping velocity, it’s easier than ever for things to drift out of sync. Your prompts, skills, and tools now need to be under version control and regularly run through evals. You might even tap an agent to QA your product against your production deployments in addition to scanning your public documentation for inaccuracies.
But the neighborhood ain’t what it used to be
Some of what it means to be a software engineer needs to be rethought entirely. The technical complexity that powers your software used to be a moat, but that notion feels like it’s completely run its course. What matters now is the thing that you choose to build, the way that you choose to build it, and how you present your product to your users.
In short, what matters is how you tell your story.
What you choose to build matters just as much as what you choose not to build. Since features come cheap now, it’s enticing to think that you should ship every halfway-decent idea that comes to mind. But more does not equal better. Claude might make a kid happy by giving them a lollipop, but that kid will find out the hard way that too many lollipops gives you a wretched stomach ache.
Friction in your product compounds at scale. Human users tend to get bogged down by minor bugs, blockers, or UX annoyances in your product, but agents will quickly move on to trying to build it themselves or find a different solution that doesn’t get in their way. This decision-making happens in minutes instead of building up over days or months. We need to pay closer attention to our product ergonomics than we ever have, knowing that our end users aren’t going to settle for anything less than top-tier.
There was always an expectation that the end user was human. Now, a valid user could just as easily be a bot. At Mux, we used to have a bot filter to prevent unwanted traffic or scraping. But now that bots may be desired traffic, we’ve now disabled our bot filter entirely to make sure that agents that were coming looking for answers or to learn more about our product could find it without being flagged.
The looming feeling of irrelevance
The biggest elephant in the room here is how much the job role and responsibilities have actually changed. Software engineers spent a while grasping for coping mechanisms and coming up with careful, strategic phrases like, “coding was never the hard part” or “coding was never the point.” That’s an opinion one can have, but it’s not the opinion I hold.
Many engineers built a big part of their identity on the responsibilities of the old shape of the role. There’s an immense joy in problem solving that came bundled in the job description. There was nothing like that dopamine hit when you finally figured out the solution to your problem at one in the morning.
Many engineers were left with their jaw hanging open as we’ve watched that description change entirely over the past 24 months. I’ve seen engineers need to take some time off and away due to burn out. Some even resort to leaving the profession entirely.
I get it. There was something special about finding the flow state and going in deep with your own code. Many engineers now feel a lack of ownership in code that we ship that wasn’t written by us, like we’re air traffic controllers, gazing at the various projects in motion above our heads, but never really understanding them from the inside.
It feels unfair to have a machine suddenly capable of solving problems in four seconds which used to take you a whole workday. Claude really moved right in and started rearranging the furniture, making himself at home without so much as a courtesy knock on the front door.
But our skills aren’t lost. I grew up as a builder; it’s the core of my being. I’ll use whatever tools are necessary as long as they allow me to continue to make things.
More than ever, we need to stand behind the work that we ship. We need to focus intensely to ensure that what ships is the best design and shape of the product that we have in mind. It is our responsibility to define what “done” looks like.
These three things—standing behind our work, going in deep, and defining done—are the pillars of what we carry forward in this new shape of the role. We are problem solvers at heart and, equipped with those skills, we’ll fearlessly march ahead into this unknown territory.
Software development practices of the future
The process for building software has changed forever. Mux is a remote-equal company. As such, we use Slack as our primary mode of communication. For our company, it’s the ledger, the source of truth for what has been decided and communicated.
It turns out Claude loves being able to be contacted by anybody and understanding the context behind chains of decision. What a nosy social butterfly.
Claude has a Slack integration called Claude Tag, where engineers and non-engineers can now participate in the same thread of work together in parallel and have a material impact on the resulting artifact. Historically, a front-end engineer would take a designer’s website mockup and spend hours implementing it. Then, they’d volley the link back over to the designer for review. The designer would provide feedback to the front-end engineer. Rinse and repeat.
Now, our designer can work in-step with the engineer and Claude directly on the front-end marketing page right there in Slack, the team steering Claude towards approved changes. The engineer can step in if necessary to help redirect Claude’s technical approach or provide additional input. This process has been an efficient way to get projects completed faster with less back-and-forth.
Our testing and QA strategy is also changing. The old way of testing meant we’d ship a Spec soup with flavors of unit, integration, system, and acceptance tests. Are those still relevant? Yes; the question isn’t “Should we test?” but rather “What’s the most effective way to do so?”
For that, I’m going to whip out the classic developer card: it depends. For our CLI, there’s no better vote of confidence than to task an agent with the tedious work of checking each CLI command end-to-end against a production Mux account and providing the receipts for its work. The agent should not allow the QA to pass unless the functionality succeeds with production credentials.
We used to use Puppeteer or Playwright scripts to try to orchestrate flows like this, but those were always brittle and required tons of updating. Now, eval prompts can be long-lived, reusable, and agents can adapt on-the-fly to changes in the codebase or redesigns in the UI. Agents can still succeed even when the test conditions aren’t explicitly defined, especially in multimodal circumstances like a model equipped with computer use.
As engineers who care about developer experience, our job has always been to try to educate and inspire our users, showing them what’s possible within our products. We do this by shipping compelling demos, examples, and content that help spark users’ imagination.
Now that users have agents on their team, we should design our content for the agents, too. One example we’re experimenting with is publishing a prompt library filled with common use cases and instructions telling an agent which pieces of Mux it should use to arrive at the best solution.
By clicking a copy button, a visitor can snag a prompt that we’ve meticulously designed to solve a specific task or use case and use our product as efficiently as possible, covering the exact surface area. No more confusion between what product features users should be leveraging or what our recommendation would be for a specific task; that’s not research that you need to do on your own anymore. We can maintain our recommendations and provide them to you or your agent without also managing aging example repos that fall out of date, worrying about dependency upgrades, or providing multilingual code examples like we did in the past.
Agents can read your existing codebase, learn directly from you about what your product’s objectives are, and integrate with our system all within a single conversation. Claude’s a great conversationalist. Maybe a bit too wordy at times.
Our docs owners are a small team, but with AI, we can meet you where you are in your product maturity or tech stack choices. You no longer need to translate our expertise and product familiarity into your own practices. The agents will do this work on your behalf. That’s progress.
How to succeed in this neighborhood
To thrive in these new circumstances, engineers must be open-minded, ambitious, and have an insatiable curiosity. They should be willing to experiment using the skills and knowledge you’ve built up over the years; they should believe anything is possible. Take time to grieve what you’ve lost if you need it, and then press on, knowing you are a builder at heart, and you don’t roll over when you hit a road block.
There’s one question that engineers have always loved to ask that’s now more important than ever: “Why?”
It’s essential that we continue to ask this question. Why are things the way that they are? Why are we still doing it that way? Why don’t we consider an alternative? A kid firing these at their sleep-deprived mother might send her over the edge, but you’ll never bother Claude (that is, as long as you don’t run out of tokens or hit your usage limits).
Ask questions, then ask some more. Never stop learning, writing, creating, producing, or participating. As optimistic and benevolent humans marching towards progress, we welcome the new kid in town. It’s not like there’s a choice, anyway; he’s here to stay.
But that doesn’t mean we have to leave the neighborhood. Remember where you came from and lean into it. Be welcoming and discerning. Let’s show Claude how things work in this part of town.
Written for The Pragmatic Engineer’s essay challenge on how software engineering is changing.