Alfonso Graziano, AI Lead at Nearform, is writing a book on AI-native engineering for O'Reilly, the technical publisher behind the animal-cover books on every dev team's shelf.
At the frontline, where our teams build agentic systems for organisations in complex and regulated industries, Alfonso was always going to be the one to write AI-Native Software Engineering. He's the guy who realised nobody had written it yet.
We talked to him about what's changed in the role of the engineer, what it takes to make AI agents useful on real codebases, and the one principle he'd want every team to adopt.
Q: The book opens by telling engineers the way most of them use AI is wrong. Why go in that hard, that early?
A: Because almost everyone falls into the same trap first, and that includes us. Vibe coding. You hand the agent a very high-level requirement, you trust that whatever comes back is good enough, and you never really check.
That doesn't scale. A model only knows what it learned in training, along with a set of assumptions you never asked for, and while the models keep getting smarter, they aren't perfect.
There are things we own as domain experts that they don't know, or that we know far better. Until the reader recognises themselves in that, there's no case to be made for anything more disciplined.
Q: So is vibe coding just a bad idea?
A: No, and I want to be fair to it. It's genuinely useful for prototyping, and for getting stakeholders aligned quickly.
It just isn't the whole story. Many companies went straight to it and soon found out fairly quickly it isn't the right way to use an AI assistant for most real work.
Q: You argue the engineer's role is shifting from writing code to directing the machines that write it. When did you have that realisation?
A: Around November 2025. It was the first time I had an agent good enough to hand real tasks to, and trust it to get on with them. I noticed I'd stopped being the person typing and become the person directing, which is the shift the book calls implementer to orchestrator.
It was a mental shift and a tooling shift at the same time. The agents crossed a threshold, in that they could work on the same task for tens of minutes, self-correct along the way, and handle a lot of what I'd been doing by hand.
Q: What did that change about the working day?
A: An agent that can run for 30 minutes without me checking every step is a different kind of tool altogether. They also got better at checking their own work, so the trust I was willing to extend kept going up. Within a few weeks, I was running five agents at the same time, all on different tasks.
The work itself is different now. Instead of implementing everything from scratch, you write the spec, meaning a precise account of what the thing has to do, then define the constraints, then define how the agent can check its own results. Once the spec is solid, you let it build, and you review what comes back.
Q: Most of the noise about AI coding is about individual productivity. What happens to a team?
A: That's what gets underrated, and it's why the book has a chapter on scaling this across teams. It isn't a personal trick.
Over time, you build a custom set-up around your own codebase, the rules, tests and tooling that teach the agent how things work, so it gets better at operating inside your specific context. Most productivity tricks don't accumulate, and this one does, so the teams who commit pull away from the ones who dabble.
Q: And what does it do to how people work together?
A: We're seeing smaller teams ship a lot more software, and work more tightly together while they do it, because now they write the specs together and then build to them.
If anything, collaboration matters more now. And you can't adopt this alone. AI-native engineering is a team practice, and it's something the organisation as a whole has to take on.
Q: Where did the idea to write a book come from?
A: It started as a joke, more or less. I was trying to study AI-native engineering as deeply as I could, so I went looking for the book on it and found nothing.
One weekend I asked myself a question I wasn't entirely serious about, which was what the contents would look like if I had to write it myself, based on everything I knew. I wrote that up and put it on LinkedIn.
Q: Released into the wild, then. What came back?
A: It took off in a way I hadn't expected. People started messaging me directly to ask when the book was coming out.
They wanted a clear picture of the whole landscape and were struggling to find it anywhere. At which point a contents page wasn't much use to anyone, so I approached a few publishers, weighed them up, and decided to write it with O'Reilly.
Q: There's plenty of content on AI and coding, so what weren't engineers getting?
A: The knowledge exists in articles and talks, but what didn't exist was a single go-to book that held all of it and gave you a full primer on becoming an AI-native software engineer. That's the gap the book is trying to close. It pulls from the material already out there, collected and organised in one place, so you aren't hunting for it.
From the experience of multiple teams doing this work for real on complex codebases, new builds and old inherited systems alike, in enterprises and in startups, so the practices have been tested across very different contexts. And from the conversations I've had with dozens of engineers and tech leads.
What I wanted out of that wasn't a summary. I wanted a learning path, coherent enough that someone starting from scratch today can understand what they're really doing and build on current best practice instead of guessing.
Q: Someone reads the book. What can they do on Monday that they couldn't on Friday?
A: The book is full of exercises, and it isn't meant to be read straight through. Do the exercises as you go, because that's where the value lands. If you do, you'll be able to orchestrate multiple agents at once, do spec-driven development properly, and take charge of context.
That means managing what your codebase tells the agent, building reusable capabilities on top of it, working with MCP servers so agents can plug into other systems, and building custom tooling for them to use.
Q: And what's the bit people don't see coming?
A: Those are all concrete, portable skills, but what sits underneath them matters just as much. There are mindset shifts you have to make to be an AI-native engineer, because the tools alone won't get you there.
Then there's how you stay relevant as those tools keep getting better. That's the part most people are worried about, and the reason the practices in the book are built to outlive any specific tool.
Q: What would you change about how the industry approaches AI?
A: I hope it drops some of its preconceptions about what AI actually gives you. There are still many companies reluctant to use AI, and what they're missing is a clear picture of the capabilities, the limitations and how to apply it properly. Reluctance based on a fair reading of the limitations is reasonable. Reluctance based on preconceptions is just lost ground.
What I'd like people to start doing is treating this as a tool, then upskilling on it as deliberately as they would on any other. The starting point is unglamorous. Get access and apply what you read to your own projects. Reading about it isn't enough.
Q: If an engineer takes one principle from the book, what should it be?
A: Always give the agent intent, constraints and verification together.
Intent is what you want, written as a real spec, instead of a longer prompt. Constraints are the rails, because there's always more than one defensible way to build the thing. Verification is how it checks itself as it goes, so you aren't left reviewing everything at the end.
None of these work on their own, but together they change how you work with an agent entirely.
AI-Native Software Engineering will be published by O'Reilly in early 2027. Early chapters are available now on the O'Reilly learning platform.
Want to know what AI-native engineering would look like in your organisation? Talk to us today.
But wait - there's more.
Nearform publishes real-world learnings on data & AI, engineering, and digital strategy - with more merged in weekly.
Insights
Perspectives on AI in engineering, product development, and strategy, for enterprise executives.
Community
Deep dives and tutorials by engineers, for engineers.
You may also like
