A year ago, Ward joined Hatch as a software developer. Good timing, as it turns out. Not only did he join just in time for our 10-year anniversary trip to Valencia, he also stepped into software development at a moment when the way we build digital products was about to change considerably.

One year later, we sat down with him for the very first episode of our Hatch podcast. To look back at his first year, talk about what it’s like to work as a developer at Hatch, and, inevitably, talk about AI.

Looking for more technical depth

Ward first came across Hatch the way most people find their next employer, but rarely admit in the interview: mindlessly scrolling through LinkedIn.

Meeting our CEO Sam two weeks later, however, did leave a bit more of an impression.

What Ward was looking for in particular was an environment where technology wasn’t simply a means to ship something as quickly as possible. He wanted to work with people who genuinely enjoy digging into technology, exploring different approaches and understanding how something works. In his words: he was looking for more technical depth.

And at Hatch, that curiosity is very much part of the job.

From day one to Valencia

Starting a new job always comes with a few challenges. New colleagues, a new project, new ways of working. For Ward, however, the biggest challenge on day one turned out to be something else entirely: using a MacBook…

Luckily, the actual work went a bit smoother. Ward was introduced to his first project almost immediately and joined conversations with the team about where the product was heading and how we wanted to build it. One of the things he remembers appreciating from the start was how quickly he got to know everyone. Being a small team definitely helps: there aren’t five layers to work your way through before you know who to talk to. If you have a question, chances are the person who can answer it is sitting somewhere within shouting distance.

Ward also picked a pretty good moment to join Hatch. Barely a month or two after his first day, we packed our bags for Valencia to celebrate our 10th anniversary.

Valencia turned out to be a fairly accurate introduction to life at Hatch anyway. We worked together from a coworking space, explored the city, ate very well enjoyed Valencia's nightlife. And because sitting still for a few days is difficult for us, there was some running involved too.

One year in, four projects

One year later, Ward has worked on four different projects. That variety is something he really enjoys about working at Hatch, and it’s also quite typical of how we work. Most of our projects are Greenfield: we start with an idea or business challenge and figure out, together with the client, what we should build and how technology can help us get there.

For a developer, that means you’re rarely stuck maintaining the same application for years. You get involved early, have quite a lot of responsibility and often get to follow a product from the first idea all the way to something people actually use.

At the same time, working on different projects doesn’t mean our developers are scattered across client offices. We deliberately work together from the Hatch studio, while staying closely connected to our clients through meetings, workshops and calls. For Ward, that’s an important part of the job. When you run into a technical challenge, there’s always someone with the right expertise to turn to.

You get a lot of autonomy, but you’re not left to figure everything out on your own. Especially now, with technology changing at the speed it is, that combination has become pretty valuable.

And then AI happened

When Ward joined Hatch a year ago, AI was obviously already part of software development. But the way developers used it was still quite different. ChatGPT was mostly something you turned to when you got stuck: to ask a question, generate a code snippet or help figure out why something wasn’t working.

Fast-forward one year and AI has become deeply intertwined with the development process. Tools can now generate much larger parts of an application, and that shift happened quickly enough for Ward to have a brief “holy shit, are developers still going to be needed?” moment a few months ago.

Fair question...

But working with these tools every day also makes their limitations pretty obvious. AI can get you to something that looks like a working application remarkably fast. The problem is that “it looks good” and “it works” aren’t always the same thing.

Underneath an application that seems perfectly fine can be bugs, unnecessary dependencies or a structure that becomes increasingly difficult to change. You adjust one seemingly innocent thing and suddenly something completely unrelated stops working. That’s where Ward sees the role of a developer changing rather than disappearing.

From writing every line to protecting the structure

That evolution has also changed Ward’s own idea of what good development looks like. He used to put a lot of value on writing software that was technically polished and highly performant. That's still crucial, of course, but he has become more pragmatic about it.

If AI allows us to build a useful application faster and make it more affordable for a client, there’s little reason to insist on manually writing every piece of it. The more important question is whether what we build today will still be understandable, usable and adaptable tomorrow.

That means developers increasingly need to think about the structure around the generated code. It’s about dividing the solution into clear, independent parts, so that if something breaks, we can replace or regenerate just that part without affecting everything else.

And that’s where the human in the loop still matters. Someone needs to understand what’s happening underneath, make the right technical choices and spot when AI has confidently created something that makes absolutely no sense.

The outcome matters more than the code

In a way, it's also a reminder of what software development is about. Clients don’t necessarily care about the process or the amount of code behind a product. They care that the end result works and that they can truly rely on it.

And when you look at it that way, AI opens up some pretty interesting possibilities. An application that might have taken too long or cost too much to justify building a year ago could suddenly become realistic if we can develop it significantly faster.

For Ward, it's basically getting from “I don't know if we can do this” to “yes, we can make it happen.”