I joined an AI startup, Gradient Labs, in November 2024 as a Backend Engineer. Two years later, my job title is the same, but the work I do day to day has changed completely. It didn't happen all at once; there wasn't one "big moment" when I switched from writing code by hand and started building software factories. It happened gradually and organically. My colleagues and I experimented with whatever we thought would make us ship faster, think better, and deploy with more confidence. Today, that grew into the majority of the code written by AI agents, and us architecting entire workflows in the company around them.
At Gradient Labs, we are operating in a domain that I am intimately familiar with. We build AI agents for financial services' operations. I was previously co-founder and CTO at another B2B SaaS in the customer ops space, and tech lead in customer ops at Monzo, the UK's most popular challenger bank. Having been a leader for 6 years I was craving to go back to hands-on work. Working with people I know and trust in applied AI was a perfect fit for me. A decent portion of the Engineering team at the time of writing also used to work in fintech: at Monzo, Pleo, and beyond. On average, we're a reasonably tenured bunch: the median number of years of experience is just over 10 years across engineers.
Being in a 3 year old startup that builds AI agents has forced the software engineering AI revolution onto us in a different way, unlike how it seems to be playing out in larger companies. The processes and techniques we ended up with over time are probably somewhat bolder than the industry average. And I thought it would be interesting to interrogate why.
Our journey into AI was bottoms-up, and based on trust and excitement. The combination of domain experience and culture that came "pre-installed" from the shared past allowed for a lot of trust and very little process. This, in turn, allowed us to experiment and find out what works at speed.
Here are some stories illustrating how this enabled an early-stage B2B SaaS to compete with companies 10x its size.
The first barriers that disappeared
It started with the front end. I'm guilty of describing myself as a "fullstack engineer" if an occasion calls for it, but the world of Webpack and Next.js has been a scary and confusing place for me for some years now. Before AI coding, a simple PR to our web app would've taken me at least 2 days, probably more. 1.5 of these days I would've spent on figuring out how to build and run the web app locally.
This was the first barrier that suddenly didn't exist anymore. Even in the days of Copilot and Cursor, circa late '24, with some hand-holding from GPT-4, I could make reasonably simple changes to the web product. At first, we nervously joked about how the backend engineers felt bad for dumping AI-generated pull requests for the product engineers to review, without really knowing how much slop we were sending their way. Instead of stopping us, our product engineers focused on enabling AI agents to contribute to the web product: pre-commit and pre-push checks, a component library, repository-wide rules. We migrated the web product into our monorepo. We delineated where an AI can approve a code change, excluding our design system intentionally. Now, code changes affecting only the web app can be auto-approved by the Codex Github app.
This came from engineers who take end to end responsibility for the changes they are shipping. Handing over partly-finished work, or waiting for a product engineer to unblock you in making a small tweak in the web app feels as outdated for us now, as waiting for someone else to test and deploy our code.
We traded Claude configs like Pokemon cards
When the Cambrian explosion of AI coding agents started in late 2025, adoption was almost instant across the company. Pretty much everyone used Claude Code: engineers in the terminal, non-engineers often in the desktop app.
When we started, we traded Claude configs like Pokemon cards. I would come to the office and my desk neighbour would say, "Look what I made my Claude do." Or I would complain about Claude using the wrong library, or doing input validation in a funky way, and someone would tell me about the rules they added to make Claude behave. We set up an #ai-coding channel where people would post comments, observations, and wins.
At this point, my understanding of my job as a Software Engineer was still along the lines of "ship features by writing code." I didn't prioritise following every new feature of Claude Code or Codex, not to mention every trend and prompt engineering hack on X. I knew it would speed me up, but in my head the ROI was still too low to deliberately devote a portion of my day to keeping up with the news and experimenting.
I usually just asked my colleagues to share their config with me. For a while, all of my AI coding was powered by a .claude folder I got from my desk neighbour, who, in turn, inherited it from another engineer. I didn't even look at what was inside it, nor did I care particularly, as long as it seemed to make my Claude code behave better.
To put this into historical context, this was at the peak of YouTube videos about "prompt engineering hacks", 5k-line prompts imploring flagship models to "act as a world-class expert in marketing" and tentative papers on things like "tree of experts". Then Anthropic released plugins. Shortly after, we made the logical leap of tidying up these "bootleg" Claude configs into reusable skills and publishing them to our own private repository and plugin marketplace.
We pondered for a moment if these plugins should be committed to the monorepo and shared by everyone working on it by default. In the end, we decided these should be opt-in. Everything is optional; every engineer is free to use whatever they find useful. In retrospect, I think this is a perfect example of what allowed us to evolve our AI "strategy" fast, with little frustration.
Claude skills gained a home, but that didn't stop trends going through the team. Over the last 6 months, many of us developed a growing frustration with how Anthropic models write comments in the code. I posted in our #ai-coding channel that reading Claude comments makes me feel dyslexic and got an explosion of emoji reactions sharing my frustration. A few people replied with their strategies of making Claude "speak more better", but the frustration persisted.
One day after coming to the office, I had a conversation at a literal water cooler where my colleague, an AI engineer, told me he fully switched from Claude Code to Codex. The reasons were not the kind of things you might hear considered in a top-down AI adoption strategy: better comments from OpenAI models and the fact that it had a pet. Five minutes later, my desk neighbour echoed the same sentiment, showing me how you can highlight parts of the response and open the conversation in a side chat. That was enough of a sell for me: I took a few hours to refactor my personal agent config to be portable across Anthropic and OpenAI and made the switch. I haven't used Claude Code since, but I expect this to last a couple of months at most, until Anthropic releases something that would make me switch back, perhaps for some tasks.
Around 2021, I made a switch from Emacs to IntelliJ. My thinking at the time was "why am I still torturing myself?" Jumping to a function or variable definition, breakpoints, renaming across a project, run configs, all out of the box, without having to wrangle a library with 300 stars on Github into working on the Mac OS build, were game changers for me. 3 months ago, in June 2026, I cancelled my IntelliJ Ultimate subscription. I fully moved on to Zed as basically just a file editor, for a rare occurrence of having to interfere with the agent work. IntelliJ IDEA ate up 2GB of memory on my MacBook Air and it just wasn't worth the tradeoff anymore.
Skills let me borrow other people's expertise
Our rapid adoption of AI coding didn't stop with personal agents, of course. With the place for the shared skills to live, we came to another change in how we work: communication between teams and projects. Even though our teams are often just two people, the product is evolving at such a pace that no one engineer can have a full grasp of the entire architecture or even the features we have, nor the tooling other teams use.
In my day to day work, I frequently need to query the contents of our data lake. Initially, I started by writing SQL myself, asking LLMs to remind me of the syntax, maybe occasionally asking questions like "how do I select conversations for companies that didn't have a particular feature flag enabled in the last 30 days?" Pretty quickly, I moved on to "run a query for me". To do this, the agent needs to be aware of the schema, so we iterated over a few options like running a schema discovery periodically and caching it in a JSON file locally. Sometimes it worked, sometimes it didn't. Occasionally, someone would improve the caching strategy. This continued until our Founding Data Scientist joined and brought some order into this ad-hoc experimentation.
She built the skill for querying data, which just completely took all of the admin of schema discovery off my plate. I don't know what the skill does and I don't know what groundwork was involved, but that's the whole point. In the pre-AI world, I would either have to ask her to run data analysis for me or figure out how to do it myself. And the latter would've required her to write (and maintain!) enough docs for me to do it. Now, my AI agent just gained the ability to do it all for me using the expertise of our Data Scientist.
Another instance of "talk to AI" where shared skills really came to shine was a migration to a new complex feature for our core product: a git-backed AI agent config. Before building this approach, the only way for our customers to change their AI agent's configuration was either via the web app or via the public API; under the hood we had implemented versioning of all of the AI agent's entities in Postgres. The new idea was to give customers the same control over their AI agent as they have over their own codebase.
I wasn't involved in this project. I was barely aware of it, really, or of the fact that it was pretty much completed and we had started migrating customers from the old DB-backed config to the new git-backed one. So when I had to migrate a large customer to Collaborate, I had two choices: either bring in an engineer from the Collaborate team to do it for me, or get myself up to speed.
Turns out I didn't have to do either. One of the engineers on the project wrote a skill that does the migration for you. I ran it, it failed a few times, made a few PRs, and successfully completed. I remain blissfully unaware of the backend architecture of the change. With shared skills, my AI coding agent just did it for me.
Claude doesn't spot check, it checks everything
This brings me to another notable change: how much easier it got to assess the impact of production bugs and how much more confident I, as an engineer, can be in rolling out fixes.
In principle, the workflow for fixing production issues stays the same:
Get an alert
Run a query to measure the impact, either in the data lake or on the metrics
Fix it
Run the same query again, monitor metrics
And sure, for the serious incidents, that was the workflow. The only thing AI coding changed is how quickly we can move through this checklist.
But for the occasional blips? For the bugs affecting 0.5% of traffic? For the issues that are not quite so important that we need to drop everything and do it properly, this is not what happened. What happened was more like this: a customer reports an issue, an engineer confirms it on the given examples, fixes it, rolls it out, spot-checks a few examples post-deploy, and that's it.
But for Claude, there's no cost of switching context. Claude doesn't need to spot check, it can check 100% of the pre- and post-deploy cases. Recently, what I started doing is adding 2 "monitors" for every bug fix. One is to confirm the baseline, "did this fix break something unrelated?" and one is to confirm that the fix works: no reoccurrences of the original issue. And why not tell Claude to add a metric and an alert as well? It's not me who has to remember how to write Prometheus queries or Terraform config.
The third example of a shared AI agent skill changed the way we detect product-level anomalies and communicate them with customers.
In our particular field, customer operations, the precise success metrics are often not obvious. How do you measure the number of conversations with customers where an agent, AI or human, has resolved the issue? Send a survey? Close the ticket? Check if there has been a repeat contact from the same customer within a short time window? Generally, how do you know what your agents are telling customers? You look through a percentage of conversations and review them manually, but how do you know if the selection is representative of the whole picture?
Typically, companies that use our AI agent will do their own QA and bring up deviant agent behaviour in meetings with us. "Deviant" is a loaded term: it can be anything from an integration bug to the wrong tone of voice. Before AI, these instances would've remained isolated. One is brought up, we fix it, agent config drifts over time, the issue might reoccur until someone else notices it and brings it up again. The only way to detect these instances is to run a very specific data query to see the number of conversations affected. You would then either have to remember to run this query periodically or invest in building a data pipeline that runs these queries on schedule for you. Moreover, sometimes writing a query is way above my SQL abilities, so that would've fallen squarely on the data team's shoulders.
For this, our founding data scientist built a product feature we call "signals". A signal is a query that detects specific deviant behaviour and runs on schedule. All signals can be viewed from a central dashboard. For now, they can only be viewed internally, but we're working on being able to share it with customers.
Now, when the AI delivery team gets a report of something unexpected happening in the agent, they just need to ask Claude to build and deploy the skill.
Automating the boring parts, end to end
There has been an evolution of how we submit and review pull requests over the last year as well. If one engineer vibe-codes a 5k-line PR, is it really a time saving to make another engineer review it as if it was code written by a human? We came a long way from asking an LLM to remind us about a particular API or to add some tests. If the code is fully written by an AI agent, should the "parent" engineer review it? Another agent? Or another engineer?
Over the last year, I have worked largely on integrations with support platforms, like Zendesk and Salesforce. This work is usually far from thrilling, but I found that 'boring engineering' is the perfect place to experiment with AI. In a nutshell, any integration in any B2B SaaS is just a thin API translator, from an API of a third-party platform to the product API. In practice, of course, it's rarely that simple, otherwise the whole software engineering industry would've been significantly smaller than it is.
But just like coding agents produce significantly better results than AI agents in less deterministic domains, what if the very boring nature of integrations makes it the best candidate for, gasp, full cycle automation?
This is the assumption we've been operating on recently. Instead of trying to "close the loop" with the whole product, decide wholesale that PRs will be submitted, reviewed, merged, deployed and monitored fully by AI agents, what if we limit this to the boring parts?
This is the project I'm working on right now. Step one was to let the Codex reviewer auto-approve PRs in the integrations sub-system. Step two was to submit pull requests with the Github app credentials rather than credentials of the human engineer. Step three is to resolve production issues (with human review): monitor errors and metrics, submit a PR, wait for it to get reviewed, deploy and monitor again. This is where we're at now, but the process is still semi-automatic: the "auto-resolver" runs on my personal laptop, and uses my personal credentials to access the tools it needs. The next step is to take it to the cloud.
Ultimately, what makes this kind of experimenting possible in a company that runs customer operations for Europe's largest fintechs is trust. Trust in your colleagues to own the risk of shipping code that no human eye has seen to production. The balance of safety controls and speed is a very unique function of a company's size, industry and culture, so your mileage may vary.
The upside, as I see it, is completely changing the B2B SaaS sales cycle, especially for companies that sell to mid-to-large enterprises. Where before there were FDEs and careful weighing of whether spending weeks on building an integration on a punt to close a deal was worthwhile, now there could be autonomous AI agents driving the cost of integration down to near 0. If that doesn't make our sales and marketing teams happy, I don't know what will.
None of this is limited to our engineering team, far from it. The AI delivery team, people responsible for integrating our agent into customers' systems and workflows, have the same access to the data query skill engineers do. They regularly make PRs to the platform to fix whatever can be fixed without involving engineers. The marketing team has a skill automating targeted accounts outreach, including generating landing pages for large accounts. The design team is building live prototypes.
What the future looks like
In the grand scheme of things, this is as smooth a transition to the new way of working as anyone could hope for. But even in an environment as experimental as an early stage startup, it comes with some trepidation on the part of the engineers.
Apart from the existential fear of being automated out of our jobs, there's a question: what happens with the code base built almost entirely by AI in the long term? We've been going balls to the wall with AI for a year. We only recently appointed the Head of Product. What happens in 2 years? 5 years? What happens when the barrier of adding a new feature is this low? If we thought legacy codebases were bad before, what is in store for us now?
Another factor in the changing world of software engineering is not just the ability to adapt but also whether we're going to like the new job. I heard from the best engineers I know that the focus time, the deep work time is gone. Before AI coding agents, you planned a feature or a refactor, maybe wrote a proposal, maybe had a few debates around it and then you sat down and wrote the code. Now it's just wrangling 7 Codex sessions and swearing at the model.
One thing I'm not worried about is that either B2B SaaSes will go out of business or software engineers will be automated out of jobs. I have been in the field of customer ops for about 8 years now: first at Monzo, then as a founder of another B2B SaaS, and now as an engineer in an AI company automating ops. There are numerous problems and use cases that sound nearly trivial from the outside that have been creating jobs for thousands of managers, engineers, customer support agents, data analysts, UX designers, and many others for decades. No plug-and-play solution in the world can solve these problems in a way that works for specific enterprises in the next decade. I'm willing to bet on it.
When I was just entering the field, I often heard a sentiment from the veterans in software that this is a job where you can never stop learning. For a while, I thought it meant a new Javascript framework every 6 months (remember Ember.js?). I don't know if AI is a larger paradigm change than Assembler, or GUI or the Internet were. I think it is, and more, but I'm not the right person to speculate. All I know is that, at least in my opinion, this is what we signed up for.
Share post
Copy post link
Link copied