Anyone Can Take a Photo. Not Everyone Is a Photographer

Today almost everyone owns a good camera, since it's in their pocket. Yet we still hire photographers for weddings, product launches and magazine covers. A phone can capture an image, but a photographer decides what the image is about: the light, the framing, the moment, what to leave out.

AI has done the same thing to software. Anyone can now describe an app and get working code back in seconds. That's a real shift, and we use these tools every day. But the people who build software for a living should be honest about what it changed, and what it didn't.

The easy part was always the code

Writing code was never the hard part of software engineering. It was the visible part, and so it was easy to mistake for the whole job. The hard parts happen around it:

• Deciding what to build. Most failed projects don't fail on syntax. They solve the wrong problem or an unclear one.
• Designing the system. Where does the data live? What happens at ten times the traffic? What breaks when one service goes down?
• Making it secure. Generated code often runs fine and is still unsafe. It may skip input validation, expose secrets, or trust data it shouldn't.
• Proving it works. A demo that works once is not the same as software that works on a bad network, with messy data, on a Monday morning.
• Keeping it alive. Code is read and changed far more often than it is written. Someone has to own it in year two.

AI makes the first draft of code cheap. It doesn't make these decisions cheaper. In some cases it makes them more important, because more code gets produced faster, and every line is something to review, test and maintain.

What the photographer does differently

A skilled photographer using the same camera as you still gets a different result. The tool is equal; the judgment isn't. In software, that judgment looks like this:

• Knowing which suggestion to accept and which to reject, because you can tell when it's subtly wrong.
• Giving the AI the right context and constraints, instead of a vague wish.
• Spotting the missing edge case, the insecure default, the dependency nobody should be using.
• Choosing the simplest design that will still hold up in two years.

An experienced engineer with AI is faster and better. A beginner with AI is faster, but not necessarily better, and sometimes only faster at creating problems.

How we use AI at Xenora

We use AI throughout our process, including for development, testing, DevSecOps automation and documentation. We treat it as a capable assistant, not as the engineer. Every change is still reviewed by a person who understands the system, tested against real scenarios, and checked for security before it ships. Speed is a benefit only if the result is something you'd trust in production.

A practical test for your next project

If you're hiring a team that says it builds with AI, ask:

1. Who reviews the generated code, and how?
2. How do you test it and secure it before release?
3. Who is accountable for the system once it's live?

The answers will tell you whether you're getting a photographer or just a camera.

Planning a product, or inheriting one that was built quickly and now needs to be made reliable? Book a conversation with our team.