From the Flight Deck to the Software Factory

I recently joined re:cinq as a Lead AI Native Engineer. I've always preferred to keep a fairly small online footprint, so rather than putting my full name and profile out there, I'll be going by Jasper.

That's the name you'll see on my profile at re:cinq, on anything I write here, and wherever my work is shared publicly. It gives me a way to contribute, write about what I'm working on and have a public presence at re:cinq without putting my personal identity online.

My route here is probably a little less conventional than most. It started in aviation, moved through years of software engineering and engineering leadership, and eventually brought me to where I am now: working on how teams can build software with AI agents as part of the engineering system, rather than simply adding another tool to the developer stack.

A slightly unusual route in

Before software, I spent a large part of my career in aviation. It is an industry built around clear process, disciplined handovers and an understanding that complex systems only work safely when responsibility is explicit.

When I moved into software, a lot of that felt surprisingly familiar. Some of the most painful engineering problems I saw were not caused by particularly difficult technical issues, but by unclear ownership, assumptions that had never been tested, or important details getting lost somewhere between teams.

I still bring aviation into engineering conversations fairly often, sometimes because the comparison is useful and sometimes because I have probably spent too many years thinking in checklists.

What leading teams taught me

Over time, I moved from writing code into leading engineers and engineering managers. I helped ship an e-signature product to enterprise customers, worked with Staff Engineers and Engineering Managers on their development, and spent a lot of time thinking about why some engineering teams move smoothly while others constantly feel stuck.

One lesson was that it is much more useful to measure delivery than activity. Once a team can see its own DORA metrics, the conversation changes. Instead of asking whether people are busy enough, you can ask where work is waiting, why changes are getting stuck and what is slowing the system down.

The same was true for quality. Behaviour-driven development and shift-left testing made teams faster because problems were found earlier, when they were still relatively cheap and easy to fix.

I also learned that people tend to do better work when they are given enough space to take ownership and develop. Fixed-scope cycles inspired by Shape Up, together with protected time for personal development, had a much bigger effect on the team than many of the more elaborate retention initiatives companies tend to introduce.

None of those lessons were originally about AI, but they have become more relevant as AI starts changing how software is actually produced.

Why re:cinq

Most engineering organisations I speak to have already tried AI coding tools. Far fewer have changed the way software moves through the organisation.

A developer gets Copilot, Claude Code or another assistant, but the rest of the delivery system stays largely the same. Planning works the same way, tickets look the same, reviews look the same, testing works the same way and handovers remain unchanged. Then people are surprised when the overall improvement in delivery is limited.

That was one of the things that interested me about re:cinq. The conversation starts with a different question: what should the engineering system look like when agents are doing a meaningful share of the work?

Once you ask that, the discussion quickly moves beyond coding tools. Specs, reviews, testing, platforms, team structures and responsibilities all start to look different. At that point, you are not really talking about rolling out an assistant anymore. You are talking about redesigning parts of the software delivery system.

There were three things that made joining re:cinq feel like the right move. The first was that AI is treated as an engineering problem rather than a hype cycle. Frameworks such as the AI Adoption Ladder are used to understand where an organisation actually is and what needs to change next.

The second was that I still get to stay hands-on. I did not want a consulting role where most of the work stopped at recommendations and slides. The interesting part for me is working with teams and actually building the systems with them.

The third was the opportunity to work on the same problem across multiple organisations rather than only inside one engineering team.

The first few weeks

I joined and went almost immediately into a client engagement focused on AI Native software delivery.

That has involved researching what a software factory could look like for their teams, shaping the story for leadership, and planning a 12-week pilot built on re:cinq's own agent platform, Lore.

Alongside that, I have started building something of my own. One thing I noticed very quickly is that consulting engagements often begin with the same exercise: digging through documents, old conversations, previous roadmaps and decisions to understand what has already happened and what is still missing.

So I am building a Claude Code plugin that pulls that context together first, then challenges the user on gaps before it starts drafting anything. The idea is to surface missing assumptions, unresolved decisions and incomplete context early, so that each engagement starts from a stronger baseline.

We also had our company off-site during my first few weeks, which was a good opportunity to finally meet the people behind the Slack conversations and spend some time building things together in person.

Where this is heading

There is one aviation comparison I keep coming back to.

Autopilot did not remove pilots from the cockpit. It changed what their work looked like. Less time was spent manually flying the aircraft, while more attention shifted towards monitoring systems, planning, judgement and knowing when to intervene.

I think something similar is beginning to happen in software engineering.

As agents become capable of taking on more implementation work, the value of the engineer increasingly shifts towards defining intent clearly, designing the system around the agents, creating the right feedback loops and deciding where human judgement still matters.

The role does not disappear, but it does change.

That shift is what I find interesting, and it is a big part of why I joined re:cinq. If your engineering organisation is trying to work out what that looks like in practice, there is a good chance we are working on the same problems.