Rethinking the Software Engineer's Job, One Epic at a Time

"An LLM is not a gumball machine. You don't get the best thing you've ever wanted out of one prompt."

That's the belief everything below is built on. AI model-assisted software engineering works if you've done the thinking. It breaks the second you skip it.

Building From Scratch, With No Map

When I joined Insify, I was thrown straight into building the claims platform with Roman, essentially from a blank page. Nobody could tell us exactly where it needed to go or how much time we had. It was also, by coincidence, the exact moment generative coding models started to get genuinely good.

I wasn't an early believer. I remember a story from a colleague in a previous company who visited their London office and heard that everyone had switched to an AI-integrated code editor, and I thought, I don't know if this is actually the future. Then fast forward to Insify, our Infra team leader offered to help me set up my Claude account, and I started small: asking it to guide me through problems rather than solve them. Slowly, that turned into letting it do more. Another colleague became someone I bounced ideas off constantly, and we read the same articles and pushed each other on what was actually achievable. Piece by piece, a way of working started to form.

The Evolution from Implementation to Architecture

The shift that I felt by adopting AI into my daily work was bigger than speed. Some engineering leaders predicted that most engineers will stop writing code directly and instead spend their intellectual capacity on architecture: how systems connect, where to cut corners, and where to hold the line. That's exactly the change that I observed.

Before, software engineering was a constant back-and-forth: make a decision about how the system should work, drop into the mechanics to build a small piece of it, write tests, come back up to the system view, repeat. Parts of that cycle allowed switching your brain off. Now I spend far more time upfront understanding how something should work and fit into what already exists, because the mechanical parts, which files to touch, what I'd forget to update in a package I haven't opened in months, get discovered and handled during implementation.

That doesn't make the job easier. It makes it harder in a different way, because you're only ever making hard decisions now. And the models will happily nod along with you if you let them. They slip into an agreeable mode very easily: "Yeah, this looks good, let's keep going." Getting real value out of them requires building a harness that forces both yourself and the model to genuinely understand what and why you are building something instead of rubber-stamping it.

The Week That Changed My Workflow

The real turning point came when Roman went on leave for a week and a half, right as I had an entire epic to finish under time pressure. An epic, for anyone outside engineering, is a large chunk of work that gets broken into individual tickets, each one a shippable piece. Mine was the claims communication module: letting people write emails directly in the platform instead of jumping into Zendesk.

I already knew Claude was strong at writing code, but struggles with making consistent and correct high-level decisions. So instead of diving in, I broke the epic down into unusually detailed tickets first, and mapped out the full dependency graph in Linear. Then I worked through it one ticket at a time: plan it in detail, hand the implementation to Claude, and immediately start planning the next ticket instead of watching a session run. I took special care to ensure every semantic decision was made by a human, while handing off as much of the mechanics as possible. Within a few hours, I had four or five sessions going in parallel, each building a different piece of the feature.

By the time a PR was ready, CodeRabbit had already reviewed it, and I'd have Claude evaluate and apply whatever made sense before I even opened the file myself. Humans stayed as the last gate, but a much lighter one. What would normally have taken me a week and a half, I pushed in two and a half days.

Two Skills, Not One Big Idea

After that week, I sat down and crystallised what I'd actually done into two reusable skills.

The first handles the product manager side: turning a rough initiative into a properly scoped Linear project with detailed tickets and a dependency graph.

The second, which I call "shipping a ticket," takes a Linear ticket ID and runs the rest of the workflow end to end:

• Checks out a fresh working environment and reads the ticket context

• Forces creating a proper spec and plan document before any code gets written

• Write a test plan, so manual testing is decided upfront instead of improvised after the fact

• Implements the ticket and opens the PR

• Reads CodeRabbit's comments, evaluates them, applies what makes sense, and replies with a decision (which also helps CodeRabbit learn from future feedback and me to confirm the concern was addressed correctly)

• Leaves one self-review, then hands off to a human reviewer as the final gate

Once I presented it, people started trying it out on their own, and it's apparently working for them too. I've since built a small internal marketplace where anyone at Insify can publish and share the skills they've built with Claude. My pitch is always the same: don't treat mine as a black box, read it, adjust it, make it yours.

The Receipts We Get for Free

One thing I didn't fully appreciate until later: this way of working doesn't just make code cheaper to write, it makes the reasoning behind it cheap to capture too. Commit messages and PR descriptions used to be an afterthought. Now they're detailed by default, because the model writes them alongside the code. On top of that, we get spec and plan files that lay out exactly what decision was made at implementation time and why a piece of code looks the way it does.

That matters more than it sounds. Legacy code is hard to extend precisely because you can't reconstruct why past decisions were made. With all of this context generated essentially for free and increasingly summarizable by AI itself, understanding why a system is in its current state and how to safely change it gets a lot easier. Both productivity and scalability benefit from this.

Where It Doesn't Pay Off

None of this means every task deserves the full ceremony. Small copy changes, shuffling two components on a page, a one-field addition to a data structure: for those, I skip the spec, the test plan, the whole cycle, and just do it. The distinction I make isn't really about whether I use Claude; I still usually do, because it's good at surfacing implications I'd otherwise miss. It's about which workflow the task deserves.

I think there’s a real risk of adopting any tool this deeply: writing code by hand is a skill that quietly declines the more you lean on this. The stories on LinkedIn about people abandoning eight-month AI-built projects because they no longer understand their own codebase are a warning worth taking seriously. However, I believe this loss of understanding of your own product is fully avoidable by spending the time and effort to first reason about the design and then reading and understanding the implementation.

Why This Matters for Insify (And for You)

The framework is not really the point. Nobody prompted me to build this, I had the room to make my workflow better through the work, and then I got to watch other engineers use it their own way. That's the kind of ownership I came to a startup for, being handed a hard problem and being the one deciding what happens to it. 

If that's the kind of problem you want to spend your career on, we should talk.

We're hiring.