Connection, ownership, respect in AI coding | Trust in the time of AI

Rohan Richards, a Senior Developer at Portable, hasn't personally written a line of code in around eight months. This is a baseline now, rather than a confession. "We very quickly moved to the point of writing no code ourselves," they say. "I think myself and my peers are all at that stage, and it happened very quickly."

That shift, engineers moving from producing code to directing, reviewing, and verifying it, is the biggest change happening in software development right now. It's also the hardest one for anyone outside the engineering team to assess. The old signals used to assess developers (how much code someone wrote, the time it took) no longer indicate much, so what replaces them?

This article draws on conversations with two of Portable's most technical practitioners: Rohan Richards (Senior Developer) and Faiq Gazdhar (Technology Lead). Their answers land in the same place from different directions: the tools have changed fast, but what makes AI-assisted development trustworthy hasn't changed much at all. It comes down to three things: connection, ownership, and respect.

The shift Rohan describes isn't that the work got smaller, it moved. "Normally I would say the effort was in the middle, which is the code typing, and the thinking while you're doing it, and the testing, and the actual process of making the thing," they say. "That's been squished outwards." The bulk of the effort now sits at the two ends: planning and architecture before an agent writes anything, and review and verification once it has. "If you do the first bit right, the quality of the code that comes out is higher and more reliable."

The effort shifts under this direction compared to how coding was traditionally learned and taught. "Normally I would just jump in and start writing code and start poking around, seeing what was happening, solving the problem that way. It's like Play-Doh, you just grab it and start making," Rohan says. "But now it's like you draw it on paper first." That upfront architecture work is where Rohan locates the real engineering skill now: get the shape of the solution right before an agent starts generating anything, and the speed, quality, and reliability of everything that follows improves.

AI has even changed rubber ducking, a problem solving practice engineers have long used. Rubber ducking is the idea of explaining a problem to someone, or something (like a rubber duck), not because they'll solve it for you, but because saying it out loud gets you to the answer yourself. An AI agent can fill that role now. The risk is expecting it to do more than that: to fill the hole, rather than get you thinking.

What hasn't changed is what the work is actually for. Faiq's clearest verification question, the one he comes back to whether or not AI wrote the code, is simple: "Is the code doing what's needed to solve the problem? Has it done more than what's needed, less than what's needed, different to what's needed? That's the main thing." He's questioning that "good software" is a fixed target AI can aim at on its own. A large language model reflects the average of everything that's been built before it, not the specific context of this client, this user, this constraint. "What I think is good is not good for another person," he says. "So what I think is ‘good’ in any context is based on the context I'm in." Deciding what's actually needed, in this context, for this person, is still a human and a team judgement call.

And Rohan is direct about the relationship that sits underneath all of it: it hasn't moved. "It's never mattered to a client how the code gets made," they say, pointing to a comparison from before AI was part of the conversation, when the question was whether a client was comfortable with offshore outsourcing. "Who's writing the code doesn't matter. What matters is the quality of the product." The obligation to deliver that quality, and to be able to answer for it, sits exactly where it always did.

Rohan has a name for the failure mode this replaces. "Vibe coding, to me, that's a swear word. We don't vibe code at Portable." The test for whether it's happening isn't whether AI wrote the code but whether the person who shipped it can explain it. "Ask them why a decision was made. Why did you build it that way? If they don't have an answer, if they just blindly trusted the agent and didn't have a conversation back and forth until they had a good understanding of the problem and the solution, that's a red flag."

The line Rohan draws is unambiguous: "You cannot say, 'Claude did it, sorry.' It's you. No one else." An engineer didn't type every character, but they should have planned it, monitored it, and reviewed it closely enough to own it completely: why it was built that way, how, and what it solves. "Ownership starts at the beginning, and you have to carry it all the way through."

Faiq's version of the same lesson came from watching himself nearly get it wrong. Deploying some infrastructure, he hit a documented feature that wasn't working, and spent close to a day going back and forth with an AI agent trying different fixes it suggested. "It kept saying, 'this isn't working, let's try this, or let's try that,' and I let it try." He eventually looked up the exact error message and found that one other person had hit the same fresh, undocumented defect the day before. "Pre-AI, I wouldn't have spent that time. I would have looked it up straight away. With AI, I let the agent try various approaches, while I did other tasks on the side. That's the difference now." The AI tooling didn't cause the mistake. It made it easier to avoid the two minutes of thinking that would have prevented it.

The practical version of ownership, for anyone managing engineers rather than writing code themselves: ask why, specifically, something was built the way it was. Ask to see the plan before the build starts, or the mock-up, or the QA report. "Getting evidence to exist in places you can use it," as Rohan puts it. If a document was written but nobody can point to how it shaped a real decision, ownership hasn't happened yet, whatever the process says on paper.

The second potential failure mode shows up in the artefact developers hand to each other every day: the pull request. AI can generate that description as easily as it generates the code. The risk, Rohan says, is volume without judgement. "One of the risks here is that you hand somebody a PR that's a novel written by AI that nobody can read. Nobody's even going to read it. It's completely useless." Faiq described the same problem from the other side of the screen: comments on every line, a plan committed alongside the code, a readme that keeps growing. "Am I supposed to read all of that? There's a lot of noise. Self-documented code is far superior than verbose comments."

Rohan's standard for what counts as respectful is direct: "If it's too much for you and you're not even going to review your own PR description, then it's not respectful to expect anybody else to do it." The obligation runs in both directions. A reviewer is expected to actually read the work, not skim and wave it through, "looks good to me" isn't good enough on its own any more, Rohan says. But that obligation only holds if the person who produced the work did the same thing first. "You must expect someone else to be able to read it and process it properly. So you need to be able to do it yourself first."

The question worth asking, for anyone reviewing a team's output from one step removed: did you read this all the way through? If the honest answer is no, from the person who wrote the description, that's worth noticing before anyone else is asked to.

The third principle is the one nobody plans for, because it isn't a step in a process. It's what happens to the people doing the work once fewer of their problems require another person.

Rohan noticed it almost immediately. "I picked up on that very early. I was almost immediately feeling isolated." The fix isn't automatic, it's a discipline they've built deliberately. "All I do is make sure I'm reaching out to people and connecting. That doesn't even have to be about work. Just have a conversation with a human, vent about how annoying AI can be sometimes, share strategies." Text isn't quite enough, in their view. "I think we need to be in person if possible," or failing that, a call rather than a message. "I think that's more important now than it has ever been."

Faiq's account of the same pressure points at something more structural. People who thrive on doing several things simultaneously, he says, get an obvious productivity boost from running AI agents in parallel. But it comes at a cost to the people around them. "It doesn't build an inclusive space for others to join in and build things," he says. "The way tools have developed, it has further isolated developers. Coding tools are built for a single person to do everything. It's very hard for teams to use AI tools to develop one application together." That's not a comment on anyone's character. It's a description of what the tools were built for, and a warning that a team can be technically productive and functionally fragmented at the same time.

It also means a technical lead's job now includes something that used to sort itself out: managing a genuine spread in how people are choosing to work. "People are at different spectrums," Faiq says. Some want to keep coding by hand; others barely want to look at the code at all. Left alone, that gap tends to calcify into the kind of tribalism software teams have always been prone to. Bridging it, deliberately and without letting either side dig in, is now part of the job.

Strip away the specifics and the same few questions recur across both conversations, useful for anyone working with teams creating AI-assisted code outputs.

For ownership: can they tell you why something was built the way it was, in their own words, rather than pointing back at the agent? Have they seen the plan through from decision to delivery closely enough to defend it in a room?

For respect: did they read their own pull request from start to finish before asking someone else to? When they review someone else's work, are they actually reading it closely enough to catch something, or moving quickly enough that "looks good to me" is doing all the work?

For connection: when did this person last ask a colleague for help, or offer it, rather than going straight to an agent? Are they still turning up in the team's shared spaces, in person or on a call, not just producing work faster on their own?

And one that checks all three at once: when something doesn't work the way an agent said it would, does the person pause to understand what's actually happening, or move straight to the next suggestion? A moment of real understanding is usually faster than it looks.

These are questions good engineering teams have always had to answer: do you understand what you built, can the people around you make sense of it, and are you still actually talking to each other. AI changed how fast a team can move and how much a single person can produce. It hasn't changed what answering those questions well requires.

Neither Rohan nor Faiq claims to have this fully solved. Rohan's clearest open problem is scale: the techniques they've developed, like having an agent check its own work against a mock-up before handing it back, were built alone, one project at a time. "Solving all of these problems team-wide, the sharing of that knowledge, is difficult. A lot of these techniques I've built in isolation. It's hard to do at scale and hard to do reliably." Good practice existing in one person's head is not the same as good practice a whole team can rely on.

Faiq's open question sits a level up. He'd read a post that morning from a seasoned developer who described no longer reading any of the code his AI agents produce, relying instead on a wall of tests and constraints to build confidence in the output. It stayed with him as a question rather than an answer: if nobody's reading the work, how would you know the tests themselves are asking the right things? "What is it that we're really achieving with this? Do we want better software? Better outcomes for people? Quicker outcomes? Cheaper outcomes? I don't think anyone's ready to answer that question yet."

The tools will keep changing, the pace will keep increasing, and the questions that actually determine whether a team's use of AI is trustworthy don't get easier to ask just because they get more urgent to answer. The ability to think critically and in context will be the difference maker, as it long has been.