Engineering Is Becoming Beekeeping

What it's like to be a frontend engineer at the end of 2025

Running a dozen agentic coders in parallel makes me feel less like a software engineer and more like a beekeeper.

At the start of 2025, AI-assisted coding was just powerful autocomplete. Tab-tab-tabbing through suggestions. Copilot finishing your sentences. A mostly hands-off test-writing experience. But you were still the one writing code.

By the end of 2025, a task I’d normally spend an afternoon on is now a single-turn afterthought¹ for Claude. It’s so simple, and I’ve grown so much confidence in the outputs, that these days I always have many tasks underway at the same time.

What I Mean by Beekeeping

A beekeeper has thousands of bees working across multiple hives. Those bees are harvesting pollen, pollinating other flowers, and making honey. Am I aware of what each bee is doing at any given moment? No. Do I care? Not really. Honey shows up at the end. That’s what matters.

But I’m not hands-off. I manage and keep their habitat safe. I provide the structures they build their hives on. The frames, the boxes, the conditions for success. A beekeeper isn’t just someone with swarms of bees in a field who sneaks in at night to steal honey. The beekeeper builds the environment that makes the honey possible.

And bees can sting. Without the right gear and practices, you get hurt. The protective suit, the smoker, the careful movements. In code, that’s patterns, documentation, tests. The guardrails that keep the stings to a minimum.

That’s what being a software engineer feels like right now.

The Shift

For years, a large part of an engineer’s value was tied to holding context. Understanding the system so completely that you became a kind of living documentation. Knowing exactly which file that weird edge case lives in. Remembering why we made that tradeoff three months ago. The deep knowledge was the superpower.

With tools like Claude Code and Droid² (and many others), that context doesn’t need to live in your head anymore. It can live in your documentation. And by extension, it lives in the LLM.

When you offload context, you free yourself to scale your own attention. To work on multiple features in parallel without going crazy. To stop being a single point of failure and start being a beekeeper.

Documentation Became Load-Bearing

At most places I’ve worked, docs and tests were important in theory. Yes, we’d love to have beautiful, meaningful documentation. We’d love comprehensive test coverage. But there was never enough time, never enough incentive. Some incidents would expose the need for better test coverage, but fixing the immediate problem and shipping the next feature always won.

Useful documentation and extensive code coverage now directly improves the output of your AI agents. The more automated tests you have, the less manual testing you do, which means a tighter feedback loop: write better docs → automate testing → get better code → ship faster. The incentive finally lines up with the aspiration.

At the start of 2025, our codebase had a README. Now we have a comprehensive set of behavioral documents that guide agents depending on their task at hand.

## When to Read Additional Docs
Before starting work, decide which docs are relevant and read them:

| Doc                      | Read when...                             |
| ------------------------ | ---------------------------------------- |
| `docs/testing.md`        | Writing or modifying tests               |
| `docs/design-system.md`  | Working with styling, color, icons       |
| `docs/architecture.md`   | Creating new routes, action, loaders     |
| `docs/code-quality.md`   | TypeScript patterns, hooks,accessibility |
| `docs/user-interface.md` | Buttons, inputs, dialogs, modals, etc.   |

This is documentation for humans and agents now. It’s the frame the bees build on. We broke our monolithic context into focused docs: testing patterns, design tokens, component conventions, architecture guidelines. Each one is a piece of the hive structure.

What My Day Actually Looks Like

I start with a few features as Linear tickets. Maybe they’re a little fuzzy:

1. As a user, I should be able to upload a CSV to my Logic Doc and have the doc’s agent execute once per row

2. As a user, I need to see potential errors and warnings that might cause unexpected output when my agent runs

3. As a user, I want to create a new Logic Doc from anywhere in the application

I create a git worktree for each feature. Then I run our /prd command with Claude:

Let’s write a PRD together and then save it in a markdown file. Ask me one question at a time until you have enough information to write a PRD. In between questions, use your general knowledge + traversal of our codebase + ability to search the web to answer questions that you can answer to fill in the blanks without needing to ask me.

The agent asks me questions, one at a time, and fills in gaps using what it knows about our codebase and searching the web. As part of this, we spec out several UX concepts for each feature, along with different UI implementations of those concepts.

Once I have PRDs with multiple design directions, I spin up Droid in each git worktree and have it implement each one. Each concept gets built as a different route, in context within the app, so I can test each design in the browser with real data immediately.

In less than an hour, I have multiple fully functional features, each with several design concepts to evaluate. Not mockups. Not prototypes. Real working code I can click through.

Build Ten to Throw Away

Remember the old advice? “Plan to throw one away; you will anyway.”³ Build it once to learn what you didn’t know, then build it for real. Now we can scale that advice.

When the effort cost of code production is this low, you can build ten to throw away. Across three features. In parallel! You can get to the heart of a problem faster, see it from different angles, and find the friction. The low-cost production allows for high-volume iteration to find quality.

After testing each concept, I run our /design-review command:

Let’s review multiple implementation approaches for a PRD and synthesize them into a cohesive design direction. First, read the original PRD to understand the requirements. Then ask me for the file paths to all implemented approaches. Read each implementation thoroughly.
Once you have analyzed all approaches, guide me through a structured comparison:
1. Summarize each approach’s key characteristics
2. Evaluate each against the PRD requirements
3. Identify tradeoffs
4. Surface risks or gaps
5. Ask clarifying questions about priorities

Continue the conversation until we naturally arrive at a direction together.

Through a structured back-and-forth, we pull the best parts of each approach into a final design. Another /prd pass to validate. Back to Droid to build the real version. Team feedback, iteration, polish, ship.

What I Actually Do Now

My job shifted. I spend less time writing code and more time:

• Maintaining the hive: Keeping CLAUDE.md and our focused docs accurate and useful

• Building new frames: Creating patterns and conventions that agents can follow

• Evaluating honey: Reviewing parallel explorations, finding what works

• Asking good questions: The /prd and /design-review workflows are really about asking the right questions to converge on good answers

The deep knowledge is encoded now. Into documentation that used to feel optional but is now the infrastructure upon which all of our code is written.

Code is still important. It’s the thing users interact with. But it’s become more commodity-like. The value of how to write code shifted upstream: documentation, patterns, architecture, decisions about what to build and why. The stuff that shapes what the agents produce.

Right Now

What’s exciting, and what keeps me on my toes, is that next week a new model release could render this entire workflow obsolete, or at least significantly alter it.

Working like this is exciting. There’s a playfulness to it. You can try things without committing. You can explore without sunk costs weighing you down. You can work on three features at once because you’re not holding all the context in your head anymore.

The bees are making the honey. We’re keeping the hive healthy.

Logic is built for the beekeepers. Check us out!

1. Single turn completion is the LLM semantic equivalent of getting it right on the first try.

2. Droid is an agentic coding tool. Think Claude Code but it runs in the cloud and you can spin up a fleet of them.

3. Fred Brooks, *The Mythical Man-Month*, 1975. Fifty years later and he’s still correct.