At WhaleHawk, I lead an engineering team of five. We build a sales intelligence platform for healthcare executive prospecting. That's a small team by any measure, and with the right AI workflow, it's the right size.
Why do we keep our team this size? Building your people assets at the end of 2026 is not about putting bodies in seats. With the power of the coding bot, it's actually a liability to host that approach -- even a partial degree of misdirection will throw a coder seriously off course with the tools at hand.
With our team, we stopped treating AI as autocomplete and started treating it as the workforce, with one non-negotiable rule:
The engineer is the decision point. The agent does the work.
If you're a founder or eng leader planning next year's team, here's my take. A small team with an AI workflow is no longer the scrappy option. It's the new default, and how disciplined your team is will decide how far and how fast you can go together.
The rule is simple. Living it is not.
"Engineers decide, agents execute" sounds obvious. Actually putting it into practice is a different story -- especially on a small team where everyone has real autonomy and nobody is waiting around for permission.
Autonomy is why small teams move fast. It's also how a codebase quietly fills up with decisions nobody made on purpose. Hand an agent a vague ticket and it will make a dozen design choices for you. For me, as the one driving our technical and product direction, that is terrifying.
To combat this -- and I do mean combat, because it takes an active defense -- we built a process with one job: make sure every meaningful decision is made by a human, out loud, before an agent writes a line of code.
How we work: decisions first, code last
- Talk it through. Every piece of work starts as a conversation, and it is based on a real need -- an engineer should never write code for a feature we cannot explain the requirements for.
- Write the proposal. It covers what we're building and why, plus mockups and other assets from the rest of the team. People have to read it and approve it, and most importantly, talk about it.
- Write the technical spec. The spec is essentially pseudocode, and is our internal pulse check -- are we alive and making the decisions for how this fits into our system? Are we following engineering best practices? Is this thoughtful?
- Plan it in Linear. We create a project and milestones. That's the map of how we'll get it done, usually broken down into thoughtful chunks of work. This keeps the scope manageable, and can help us understand timelines and expectations for QA.
- Scope the issues. Each Linear issue is a piece of work of roughly 800 lines of code or less, and directly solves the problem captured in the milestone.
- Attach everything in the PR. We want the agent empowered to go back through our history, understand the decisions made and why, and debug according to spec, not to symptom. Each PR is sized so our pipeline manager can review it against the spec in one pass.
Why we cap issues at about 800 lines
Scope is the agent's guardrail. An issue capped at roughly 800 lines is small enough to review in one sitting and specific enough that the agent can't wander.
It also leaves a trail. When something goes wrong, we can regress to a specific issue and say, "Okay, this is where we go back and fix what we did." The agent can follow that same trail, because the work was scoped into issues from the start.
Big, fuzzy tickets are where AI-generated code goes to rot -- the agent fills every gap with a guess, and you don't find out which guesses were wrong until something breaks. Small, scoped ones keep the code clean, keep the engineer in charge, and leave a paper trail.
The handoff is the leverage
Here's the part that changes the math for small teams. Once the proposal and the spec are approved, and the pseudocode makes sense for the application, I can hand off the implementation completely.
Is that blind trust in the robot? Not even close. Handing off the build is not about stepping away -- it's about doing the hard thinking up front, so that by the time the coding bot picks up the work, there is nothing left for it to decide. A senior engineer's value was never in the typing. It's in the design.
The leverage depends on knowing where to hand off and how to hand off well. Hand off too early and the agent makes your decisions for you. Hand off too late and you've done the work twice.
The hard truth: review becomes the bottleneck
AI didn't remove the bottleneck. It moved it from writing code to judgment.
A process like this takes full-time people and all of your attention -- especially when you're also managing a team and have engineers writing code. Designing work for agents takes real energy to get right, and so does handling that work as it comes back through the pipeline.
Our review is specific. The reviewer reads the pseudocode spec, then measures the Linear issues and the PR against it. Did we deviate from the plan? Did anyone, human or agent, make a decision outside what the spec covered? If so, it's caught before it merges.
That's how we stay on the same page and keep the codebase clean. It's also why I won't pretend this is free. If your senior people are already at capacity, adding more agents is not going to add output -- it's going to add unreviewed code, and that's a liability you'll be paying down for months.
What this means if you're building a team
- Small is the default now. A handful of strong engineers with agents can cover ground that used to take a much larger team.
- Hire for judgment. When agents do the execution, the people you hire are the decision-makers, not function writers.
- Invest at the front. Proposals and specs aren't bureaucracy. They're how humans stay in control of what gets built.
- Scope ruthlessly. Small issues and small PRs are what make agent output reviewable.
- Protect your reviewers. Whoever owns the pipeline is your real constraint. Staff and schedule around them.
The teams that win won't be the ones with the most bodies in seats. They'll be the ones where every decision has an owner -- and the agents never have to guess. Engineering in 2026 hasn't been easy; this is a new type of difficult that we all have to wrap our arms around to get right.
How is your team handling the handoff between engineers and agents? Tell me what's working, and what isn't, in the comments.
Top comments (0)