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 joined during one of the more interesting periods to be working in software development.

AI was already changing the way we worked, experimented and built products. But over the course of Ward’s first year, the tools became considerably more capable, moved much closer to the actual development process and opened up a whole new set of questions about what good software development looks like.

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 where AI is taking the job.

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 in a field that is evolving as quickly as software development is today, that combination has become pretty valuable.

When AI moves into the development process

AI itself isn’t new to the way we build software. What has changed remarkably fast is where it sits in the development process and how much of that process it can take on.

A year ago, developers were already using AI throughout their work: to explore solutions, generate code, troubleshoot problems or speed up repetitive tasks. Since then, we’ve seen those capabilities move much closer to the actual building process.

Today’s tools can generate increasingly large parts of an application and iterate on them at a speed that would have been difficult to imagine not that long ago.

Even when you work with this technology every day, that pace can occasionally trigger a “holy shit, are developers still going to be needed?” moment. Ward had one a few months ago.

Fair question. But the more you work with these tools, the clearer it also becomes where the real challenge lies. Getting AI to produce something that looks like a working application can be remarkably fast. Making sure what sits underneath is solid enough to actually build a product on is something else entirely.

There can be bugs, unnecessary dependencies or architectural decisions that only become problematic once you start changing or scaling the product. You adjust one seemingly innocent thing and suddenly something completely unrelated stops working.

That’s why, for Ward, the interesting question isn’t whether AI replaces developers. It’s how the developer’s role changes when generating code is no longer the difficult part.

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 how we get there.

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, reliable and adaptable tomorrow.

And that puts more emphasis on the decisions surrounding the code. Developers need to understand how to divide a solution into clear parts, how those parts interact and where dependencies can create problems later on. If something needs to be changed or regenerated, you want to be able to do that without accidentally bringing down everything around it.

That’s also where technical expertise becomes more important, not less. AI can generate an impressive amount of code, but someone still needs to understand what’s happening underneath, make the right architectural choices and recognise when a perfectly confident answer is actually a terrible idea.

The outcome matters more than the code

In a way, all of this brings software development closer to what it was always supposed to be about.

Clients don’t necessarily care how many lines of code we write or which parts were generated by AI. They care that the end result works, that it’s solid and reliable, and that it solves the problem they came to us with.

AI gives us another way to get there, and in some cases, considerably faster.

That opens up some pretty interesting possibilities. Products or experiments that might previously have taken too much time or budget to justify can suddenly become realistic. We can test ideas faster, learn sooner and spend more of our time on the decisions that actually shape the product.

For Ward, that’s ultimately the interesting part of being a developer right now. The tools may change how much code we write ourselves, but not what we’re trying to achieve. It’s still about getting from “I don’t know if we can do this” to “yes, we can make it happen.”