From Code Writers to AI Orchestrators: How We're Adapting at BNB

Every Tuesday, the BNB engineering team meets for an hour to discuss what we’re working on and learning. We wanted to share those conversations more broadly, so we’ve started having AI take notes and draft blog post recaps. We review and edit them before publishing. Here’s one of those discussions.

---

Something fundamental is shifting in software engineering, and we’ve been feeling it at Brand New Box. The rise of AI coding assistants is changing more than how we write code, it’s redefining what it means to be a software engineer.

We recently had a team discussion about this transformation, and I wanted to share our honest perspective on what we’re experiencing, how we’re adapting, and where we think this is all heading.

The Identity Question

Here’s the uncomfortable truth: writing code used to be the fun part. The creative problem-solving, the satisfaction of crafting elegant solutions, the joy of building something from nothing. That was the heart of why many of us became engineers.

Now? It increasingly feels like we’re managing AI rather than creating. One of our team members described it as moving from “a block builder game to Roller Coaster Tycoon.” It’s a fundamentally different type of engagement. Some days, the work feels less like craftsmanship and more like quality control.

Many engineering teams are grappling with this right now, whether they’re talking about it openly or not.

What’s Actually Changing

The shift we’re experiencing mirrors historical transitions in programming, like moving from assembly to C, or from C to higher-level languages like Ruby and Python. Each abstraction layer eliminated lower-level concerns and changed the day-to-day work of engineers.

But this transition feels different in a few key ways:

Everyone’s being forced to “level up.” Junior engineers are suddenly expected to do the planning and architectural thinking that used to be reserved for senior roles. The profession now requires managing AI tools rather than direct implementation, and that’s a significant leap regardless of your experience level.

The core competencies are shifting. Planning, reviewing, and process management are becoming the new essentials. Reading and understanding generated code for quality control is now as important as writing it yourself.

Code quality requires new vigilance. AI tends to create one-off implementations rather than reusing existing abstractions. Getting AI to identify patterns in your codebase and maintain architectural consistency is genuinely difficult. We’ve found ourselves investing more in test-driven development specifically to guide AI decisions and keep things coherent.

How We’re Adapting

We’re not just observing these changes. We’re actively experimenting with how to work within them. Here’s what’s working for us:

Embracing Opinionated Frameworks

AI agents excel with well-established, opinionated frameworks like Rails. This has actually reinforced our commitment to our current tech stack rather than pushing us toward something new. The AI performs well because Rails has strong conventions and extensive documentation. No immediate plans to abandon what’s working.

Building Guardrails

We’re implementing what we call “architectural decision layer specs,” which are essentially linting rules that enforce the use of existing abstractions. We’re also investing heavily in detailed documentation (Claude.md files) that teach AI about our existing code patterns. It’s extra work upfront, but it pays dividends in consistency.

Setting Boundaries

One unexpected challenge: when AI is always accessible via text, the temptation to code constantly is real. We’re being intentional about work-life boundaries. Using AI for morning briefings on open PRs and daily tasks is helpful; letting it blur the lines between work and personal time is not.

Finding New Sources of Satisfaction

This might be the most important adaptation. We’re actively looking for, and finding, joy in different aspects of the work:

• Process optimization and workflow improvements
• Solving harder problems faster than we ever could before
• Polishing user experience and accessibility
• Architectural planning and identifying useful abstractions

The satisfaction is still there. It’s just coming from different places.

Rethinking Our Value Proposition

Here’s something we’ve realized: our clients have never actually cared about the underlying code. They care about getting a usable product that solves their problem. What matters to them is the working product.

This is liberating once you accept it. We’re shifting our positioning from “we write good code” to “we deliver usable products.” The focus is moving toward product ownership, user experience, and process optimization. We’re becoming software consultants who create usable, self-documenting applications that reduce our clients’ support burden through better UX design.

We see this as growth.

Where We Go From Here

We’re not claiming to have all the answers, but here’s our current thinking on the path forward:

For skill development: Master the art of directing and managing AI assistants effectively. Develop expertise in identifying and creating useful abstractions. Focus on architectural thinking and process design. And critically, maintain the ability to read and understand generated code. You can’t quality-check what you can’t comprehend.

For staying current: We’re staying approximately two weeks behind cutting-edge AI developments. Let others work out the issues first. Balance staying current enough to remain competitive with avoiding constant tool churn. The switching costs for new AI tools deserve the same consideration as switching costs for frameworks.

For workflow: Continue experimenting with AI tool boundaries. Develop better methods for teaching AI about existing codebase patterns. Refine test-driven development practices to guide AI implementation. Explore automated documentation and demo generation for new features.

The Honest Take

The software engineering profession is being transformed, and there’s no going back. Some engineers will thrive in this new landscape. Others will struggle to find the same fulfillment they once did. Both responses are valid.

At BNB, we’re choosing to lean into the change rather than resist it. We’re finding new ways to deliver value, new sources of professional satisfaction, and new skills to develop. The work looks different than it did two years ago, and it’ll probably look different again in another two.

That’s simply the nature of working in technology.

The engineers who adapt, who learn to orchestrate AI effectively while maintaining the judgment and architectural thinking that AI still can’t replicate, will continue to build things that matter. We’re betting on being those engineers.