AI Tooling at Sequence: A Zero-to-One Perspective

Hey! I'm Elizabeth, a Senior Product Engineer at Sequence.

At Sequence, we're given access to cutting-edge AI tooling, integrated right into our everyday workflows. From the outside, that can look intimidating - especially if your current role or organisation hasn't enabled you to keep up with modern agentic engineering practices. Maybe you're worried that everyone around you has quietly become three times more productive, and you're the one falling behind. I'm here to say it's never too late. AI tooling is moving so fast that everyone is a beginner at something, all of the time. This is the roadmap I wish I’d had when I was getting started.

I come at this from a somewhat unusual angle. I joined Sequence in March 2026, and just before that I took a five-month planned sabbatical. I'd used AI in my prior role, but AI in a code editor was still at the "tab-completion" stage. GitHub Copilot could be helpful - predictive, fast, occasionally uncanny - but it was essentially enhanced autocomplete. We also had a self-hosted Gemini, but the barrier to using it was high: you'd paste your code into a ChatGPT-like box and, more often than not, get back something that looked nothing like our codebase conventions.

When I left for my sabbatical, I was optimistic. "It's the worst it'll ever be" was a phrase I used a lot, but agentic engineering just wasn't there yet. Little did I know that the five months I'd spend scuba diving the depths of the Galápagos and climbing mountains in South Africa would be some of the most transformative in the industry's history.

The five months where everything changed

For those who don’t devour their daily TLDR AI newsletter like its Christmas morning, a brief, non-exhaustive history of what happened during my time off:

• September 2025 - Claude Sonnet 4.5 and OpenAI’s GPT-5-Codex had just launched. This is roughly the world where I left it. Good coding models, and Codex could now run autonomously for hours rather than finishing a single line.
• October 2025 - Claude Haiku 4.5 and Cursor 2.0. Frontier-ish coding trickled down into a cheaper and faster model. Cursor rebuilt its interface around running many agents in parallel.
• November 2025 - Claude Opus 4.5 (plus Google Gemini 3). This was a real step change - Opus 4.5 was the first model to cross 80% on SWE-bench Verified.
• December 2025 - OpenAI's GPT-5.2. OpenAI's answer, leaning hard into long-running, multi-step agentic work.
• February/March 2026 - The Claude 4.6 generation. By the time I was setting up my shiny new M5 Pro at Sequence, Opus 4.6 and Sonnet 4.6 were out, a Sonnet-tier model was beating the previous Opus on coding, and the 1M-token context window had gone generally available at standard pricing.

The point isn’t any single release, but its the pace at which a whole category crossed a line seemingly in the blink of an eye (which is what my sabbatical felt like once it was over!). When I left, the bottleneck in software was coding. Now, the bottleneck is deciding what to code. For someone like me who had always loved software engineering as a means of building products that solve real-world problems, rather than the physical act of coding itself, I felt like a kid in a candy store - but I was also incredibly aware that I was entering a completely different paradigm of software engineering.

Week One: A fish out of water

I'd played with Cursor and Claude Code during my time off, but I'd never pointed any of it at a production system at scale - let alone one like Sequence, which processes millions in revenue for our customers through incredibly complex billing logic, with no margin for error.

My first day was disorienting. My new teammates were dropping "Claude" into sentences as both a noun and a verb. "I'll get a Claude on that." "Honestly, that's pretty Claude-able." “Claude is Claude-ing.” I couldn't wait to get my hands on it, but my first few attempts were a disaster.

Having spent most of my career as a backend engineer, I confidently grabbed a frontend ticket, reasoning that between my general engineering experience and this magical new tooling, I could produce something passable in unfamiliar territory. I prompted Claude to do the ticket, and it ran away from me. It made change after change, and eventually I'd lost sight of the actual problem we were trying to solve. I knew enough JavaScript and React to know I wasn't happy with the code it had written, and iterating on a pile of AI slop was only making things worse. I ended up scrapping the entire session.

On reflection, the problem wasn't Claude. It was me. I hadn't invested the time upfront to understand what Claude needed to do its job well: no planning, no context, no access to the tools it needed. I'd broken nearly every engineering principle I'd spent years honing, and expected a powerful tool to overcome that and produce something magic from a few vague instructions. That's not engineering - that's prompting-and-praying.

So I started over… properly this time. Here's what actually worked.

Agentic Engineering: A learning roadmap

1. Set Claude up to work for your organisation

The single biggest unlock is to give Claude the same access, knowledge, and tools you have.

To work well, Claude needs three things:

1. Access to the systems you work in.
2. Knowledge of how your specific codebase and domain actually work.
3. Tooling - the same commands and verification tools you'd use as a human engineer: running tests, inspecting Terraform plans, reviewing screenshots so you have a feedback loop.

If Claude can't do everything you can do, it can't do your job with you.

At Sequence we've invested heavily here. We maintain a claude-marketplace repo where we configure all our MCP and plugin connections - Slack, Linear, Notion, GCP logs, and a server for querying our Postgres read replicas.

Inside every repo we also keep rules and skills:

• Rules are the always-on guardrails and conventions Claude should follow every time it touches the code. For example, architecture.md is where we lay out the blueprint for our hexagonal architecture in the backend.
• Skills are packaged, on-demand capabilities it can pull in for a specific task. For example, adversarial-review hunts for weaknesses that traditional code review misses; and technical-planning walks an engineer through a feature-planning session and produces a detailed spec before any code gets written. Anyone can write a new skill, and we iterate on them constantly to keep pace with a system that changes every day.

2. Start in the IDE

For me, the best first introduction was installing the Claude plugin in IntelliJ and opening a Claude instance right inside the editor. Compared to your native terminal, the big win was being able to highlight a chunk of code in the IDE and ask about it specifically.

In the early days I used this almost entirely to learn, not to build:

"Explain the UseCase pattern to me, and why does it sit within the application package?"

"Why do we use it here - is that a codebase convention or a Kotlin one?"

“What’s the latest with this gRPC migration?”

I got up to speed on our architecture and on Kotlin, which was also new to me, faster than in any job I've had. But I had to actively resist the urge to let Claude write the bulk of my code straight away (although I'll confess to a few lazy "plz fix"es). Before leaning in, I wanted a genuine foundation: being able to navigate and write the code myself. You can't supervise what you don't understand.

3. Plan, read, iterate… then build

Once I was more comfortable navigating our codebase and writing Kotlin myself, I started using our technical-planning skill to plan out well-scoped tasks. I'd ask Claude to create a plan based on my requirements, read it, iterate with Claude, and once I was finally happy with it, ask Claude to implement it step by step. I'd give it explicit instructions to stop at every touch point so I could inspect the diff in my IDE and understand exactly what had changed and why. And I always staged my own commits and wrote my own commit messages. That last part is a discipline, not a chore: if I can't write the commit message, I don't actually understand the change yet.

4. Worktrees and Conductor

Once I'd built more confidence in the plans I was writing with Claude, I could send it off on longer-running tasks. But I hit a wall: one Claude per repository. Run two and they'd start a border war between branches - not fun.

Conductor fixed this. It makes it trivial to spin up a new workspace - a git worktree under the hood. If you haven't come across them before, a worktree is a separate working copy of your repo: its own folder on disk, checked out to its own branch, but sharing the same underlying git history (so there's no wasteful duplication). Each agent gets its own, so they can all work the same codebase at once without stepping on each other's toes. At a glance I could hop between worktrees, check in on what each Claude was doing, see PR state, and keep several threads moving at once.

This was the moment the "new paradigm" clicked for me. I wasn't writing code so much as running and orchestrating a small team.

Early on, I was learning fast but shipping slowly. Introducing Conductor and other multi-agent coding workflows once those foundations had started to solidify is what let my delivery speed catch up.

5. Claude Code Desktop

More recently, Anthropic has poured investment into the Claude Code desktop app, and for many of us it now covers the parallel-agents-in-worktrees workflow natively: worktree-per-session, a multi-session sidebar, an integrated terminal, plus things like Routines, Loops, rules, MCP tools, and skills all working first-party rather than through a wrapper. I personally love being able to organise my sessions into custom groups around my ongoing projects.

Some of us have switched over; plenty are still happily in the terminal or on Conductor. At Sequence, it's completely up to you how you like to organise your agents. The tooling is moving fast enough that my workflow will probably have changed again by the time you read this.

Another magic moment for me: I kicked off a remote Claude session from the Claude Code mobile app, asked it to address a Slack alert, and opened a PR - all from my phone on a lunchtime walk. It felt like a novelty, and it worked for a small, well-scoped bug fix, but I still prefer reviewing code on my actual computer before it goes anywhere meaningful.

6. Voice-to-text: the next evolution

The newest thing in my agentic engineering toolkit is voice-to-text - I've been using tools like WisprFlow to stream my thinking straight to Claude.

I know how dystopian that can sound - we're now literally talking to the machines, not just typing at them. But the biggest barrier to getting Claude to do what I want has never been Claude - it's finding the words to explain it. How many times have I said to a colleague, "I just want it to… ugh, you know what I mean?!"? Talking out loud, I ramble the half-formed version of the idea, and Claude does a genuinely good job of pulling the signal out of the noise, asking follow-up questions, and turning it into a plan far faster than I could have typed it up.

Where we’re still learning

Leaning into these tools too fast will hurt you. I've had more than one occasion where I let a session get carried away and ended up scrapping the whole thing to go back to the drawing board, resulting in wasted tokens and time. But the lesson I keep re-learning isn't so different from traditional engineering practice: small, iterative chunks. The same principle we apply to shipping - make changes small, make them often - doubly applies when the agent is the one at the keyboard. A tight leash and a short diff beat a 40-file pull request any day.

We're still iterating with these tools every day. Claude Routines and Loops are fantastic, until you have 40+ unreviewed PRs left open on GitHub for days, with no capacity to review.

When "I'll get a Claude on that" turns into 40 open PRs and zero free reviewers...

Our most recent gripe: Claude loves to inject change-documenting comments into every diff, despite several rounds of tweaking our style-comments.md rule in the Kotlin repo. And our Claudes frequently disagree with each other, which leaves us (the humans) comparing their outputs to work out who's right. I can't wait for the day the agents can just hash it out between themselves - the plumbing for that already exists between companies (agent-to-agent communication, via emerging standards like the A2A protocol), even if a seamless "my Claude talks to your Claude" isn't quite a one-click thing yet.

What's next

We have an incredibly active #learn-ai channel in Slack, where people share new tools and workflows more or less daily. The setup I've described will almost certainly look dated in a few months - which is the whole point. The skill isn't any particular tool; it's staying curious, being willing to throw out last month's workflow when a better one comes along, and getting comfortable with trying new things, failing, and iterating until you get it right.

If this way of working sounds like your idea of fun… we're hiring across New York and London! And we'd love to hear from you 😊