DEV Community: Reme Le Hane

Three AI Agents, One Spec

Reme Le Hane — Tue, 03 Mar 2026 08:56:00 +0000

There’s been a steady undercurrent of people switching tools lately. Copilot to Claude. Claude to something else. Codex quietly entering more workflows. A lot of confidence in different directions, often delivered with certainty.

I had just signed up for Claude to evaluate whether it could realistically replace ChatGPT in my workflow. Copilot already lives inside my IDE and has been solid for a while. ChatGPT fills the thinking space outside it. Codex was new to me, and I hadn’t pushed it beyond small experiments. Rather than rely on opinions, I wanted to see how they behaved when given the same real problem.

I took a feature from a production side project and gave the exact same specification to all three. No prompt tuning between runs. No follow-up corrections. Just the same instructions, copied and pasted.

The project itself isn’t the focus, but for context it’s a 3D print cost calculator that’s been live for some time. The feature came directly from user feedback: support multiple materials in a single calculation.

Modern 3D printers can switch between filament spools mid-print. That means a single object might use two or three different materials. From a costing perspective, the application can no longer assume one material per job. It needs to aggregate several weights, each with its own cost per kilogram, and still produce a stable total.

Previously, the model was simple: one material, one weight. The new version required introducing a list of material usages, updating the UI to support adding and removing entries, migrating existing saved calculations so nothing broke, adjusting the cost engine to sum across usages, and updating exports and tests to reflect the change. It was a contained but multi-layered change, the kind that forces you to think about backward compatibility before aesthetics.

All three tools produced coherent implementations. Nothing wildly off target. Nothing unusable. Each of them understood the structure of the problem and translated the specification into working code.

There was one shared oversight. The feature was meant to be premium only, and none of them added any form of gating. That detail wasn’t in the instructions, so it never appeared in the output. It wasn’t dramatic or surprising, just a straightforward reminder that these systems implement what is written. Anything that lives in your head but not in the spec simply does not exist from their perspective.

Where They Diverged

Claude wrote the most code and made the broadest structural changes. It introduced immutability into the data model and added supporting packages to enforce that pattern. It also flagged localisation concerns, something the others ignored, although the implementation itself only covered English, ignoring the other 9 languages. The overall feel was of an engineer who prefers improving the surrounding structure while adding the feature, even if that means expanding the footprint of the change.

Copilot took a more conservative approach. It extended the existing structures rather than reshaping them and stayed close to established conventions in the project. The implementation felt incremental and aligned with what was already there. Tests were adjusted where necessary, but new work was ignored as far as testing was concerned.

Codex landed somewhere between those two. Its structural footprint was closer to Copilot’s, but the feature felt more complete. The user flow around multiple materials was slightly cleaner, and the test coverage went beyond simply keeping the build green, it updated tests where necessary but also included test for the newly introduced business logic. It did not attempt to modernise the surrounding architecture, but it did seem to push the feature towards a finished state rather than a minimal extension.

Claude also took noticeably longer to produce its output. Codex and Copilot completed within minutes of each other, while Claude took roughly twice as long. That difference did not materially change the evaluation, but it was visible when running the comparison side by side.

What stood out over time was less about correctness and more about inclination. Each tool behaved like a different kind of engineer. One leaned towards structural refinement, one towards continuity, and one towards feature completeness. None of them had context about my longer-term intentions for the project, and none of them could weigh architectural disruption against speed of integration in the way a human maintainer does. They simply optimised within the boundaries of the instructions provided.

The Decision

In the end, I am not merging any of the branches as they stand. Codex is probably the closest to something I could integrate with minimal additional work, largely because its changes sit comfortably within the existing structure while still delivering a rounded implementation. Restoring a removed widget or adding premium gating is straightforward, and extending localisation properly is manageable. The path to integration feels shorter.

But the final implementation will be selective. The strongest elements from each approach can be combined, and the business constraints that were never specified can be applied deliberately. That part still belongs to me.

What this exercise clarified is not which tool is “best.” It is how differently they interpret the same constraints and where they naturally apply effort. Used in isolation, that bias might go unnoticed. Run in parallel, it becomes visible.

That visibility is useful.

Instead of choosing a single tool and treating it as the answer, there is value in letting them generate alternative implementations and then integrating intentionally. They can explore branches quickly. I remain responsible for coherence, consistency, and long-term direction.

That division feels realistic.

The Space Between Intention and Impact

Reme Le Hane — Tue, 07 Oct 2025 08:26:00 +0000

It’s been said to me that at times my responses can come across as a “no” first-unintentionally, of course, but real all the same.

Not long ago, someone on my team shared an idea they were exploring. I began with a caution, meaning to help them avoid a pitfall I’d learned the hard way. I followed up with suggestions and examples from my own experience. From my perspective, the conversation went smoothly. Only later did I learn, through someone else, that it hadn’t landed that way. They felt dismissed.

That realisation surprised me. I had genuinely believed it was a supportive, collaborative discussion. The truth is, there’s a gap in my self-awareness-a blind spot around how my words or tone might shape someone else’s perception. My intention was to guide, but the impact was to discourage.

I’ve been working to bridge that gap. Thinking has become my best tool so far-slowing down just long enough to consider how I begin a response, to pause before speaking, to ask a question instead of offering an answer. Curiosity softens the space where instinct once jumped in.

Lately I’ve also started ending my days with a short “catalytic retro.” Ten to fifteen minutes to quietly revisit the day’s interactions and decisions, asking not just what went well but what landed wrong. Wins tend to speak for themselves. It’s the misses that offer the real insight, if you’re willing to see them.

That small pause between intention and impact-that’s where growth lives.

Next time: When Accountability Feels Like Blame

The Weight of the First Word

Reme Le Hane — Tue, 30 Sep 2025 08:55:00 +0000

The opening sentence of any message often carries more weight than everything that follows. I’ve learned this the hard way.

Recently, a report shared something he wanted to pursue. I was supportive — I really was — but my first response came as a caution. By the time I circled back with encouragement, the damage was done. My intent was positive, but because I led with a warning, it landed as dismissive. If I had simply restructured the order, the conversation would have gone much differently.

That first sentence doesn’t just start the conversation, it sets the emotional tone. In leadership, where words echo longer than we imagine, that opening matters.

I’ve become more intentional in 1:1s. Mondays are blocked for them, and I build in prep time before each call. If I roll straight from deep work into a conversation, my attention is split. Reviewing notes and preparing a loose outline helps me switch context and center myself before we begin.

But no matter how much you plan, conversations have a life of their own. You can only plan your side. A loose structure keeps things anchored, but flow makes it human. The art is knowing when to guide and when to let it breathe — and remembering that the very first thing you say will shape how the rest of it is received.

Next time: The Space Between Intention and Impact

When Not Having the Answer Is the Answer

Reme Le Hane — Tue, 23 Sep 2025 08:30:00 +0000

One of the things I’ve always been comfortable with is admitting when I don’t know something. To me, it’s one of the real distinctions between the more and less experienced engineers — and honestly, people in general.

When you’re earlier in your career, there’s often a sense that you have to know, that asking questions risks exposing you. The irony is that admitting you don’t know and asking for help are both powerful strengths.

The best conversations often start with not knowing. You either dive into a discussion that unpacks the problem or you step away to do some research on your own. Both paths are valuable. And when you admit you don’t know, you make space for others to do the same. You’re showing trust, and you’re inviting the so-called “stupid questions” that usually turn out to be the ones everyone was sitting on.

That’s not to say I don’t have my moments of blurting out the first answer that comes to mind. I think fast, I talk fast, and I’ll sometimes start with a solution and work my way backwards. It can turn into a one-sided monologue if I’m not careful. Over time, though, I’ve learned to make a conscious effort to sit with the question instead.

Silence can be uncomfortable, but it’s also a tool. It gives both people space to think. Sometimes the other person uses that pause to elaborate further, and suddenly the picture looks completely different than it did when I first thought of an answer.

So when I don’t have the answer, or even when I think I do, I’ve learned that waiting — not rushing in to fill the gap — is often the best answer of all.

Next time: The Weight of the First Word

The Courage to Let Silence Do the Work

Reme Le Hane — Tue, 16 Sep 2025 08:23:00 +0000

Silence can feel heavier than words. In conversations, especially as a leader, there's an instinct to fill every gap, to keep things moving, to show that you're engaged. But I've learned the most valuable moments often come when I do the opposite-when I leave the space open.

In my 1:1s, I try to pause before responding. It's not about waiting for my turn to speak, but about listening to understand, not just to reply. Sometimes that pause encourages the other person to keep talking, to elaborate in ways they might not have if I'd jumped in too quickly. Other times, it gives me the clarity to respond more thoughtfully-or even the courage to admit I need time before giving an answer.

When I first joined Loop, someone pointed out that I had a habit of filling silence. Luckily, I caught that before I started running 1:1s with my team. Those meetings aren't meant for my voice to dominate. They're their time, their space. My role is to hold it, not to crowd it.

As for interpreting silence, context matters. In deeper conversations-whether about growth, progression, or tough questions-silence usually means thought. It's the weight of someone considering their words, reflecting before speaking. I haven't yet experienced it as something negative. More often, it's the quiet before honesty.

Silence doesn't need to be awkward. It can be an ally. The courage lies in resisting the urge to break it, and instead trusting what it makes possible.

Next time: When Not Having the Answer Is the Answer

Guiding Without Owning

Reme Le Hane — Sun, 31 Aug 2025 08:35:00 +0000

Ownership is powerful. In our team, we lean into it hard - minimal hand-holding, maximum space for people to make their own calls. Most of the time, it works beautifully. But there are edge cases where ownership slips into something else entirely.

One former teammate stands out in my memory. Brilliant mind, but he often over-engineered his solutions. Feedback came late, after days of work, when the code had sprawled into hundreds of lines across dozens of files. What should have been a simple fix ballooned into a tangle of complexity that testing inevitably sent right back.

As a lead, this was one of the hardest balancing acts I've faced. I could see where he was veering off course, and the urge to step in was strong. But my instinct is to guide through questions rather than directives. I know if I state an answer outright, my team tends to agree too quickly - and we lose the benefit of their independent thinking.

Still, accountability doesn't vanish just because you believe in ownership. In one case, after we had already aligned on a simple plan, the “fix” returned days later as a massive rewrite that didn't even solve the root issue. At that point, I had to step in and block the work. He asked me, almost exasp“Whatd, “what do you want me to do?” Not the kind of moment any leader loves, but a reminder: guiding has limits. Sometimes, you have to draw a line.

That tension is real. Letting people struggle long enough to learn, without letting the team or product suffer. Asking the better question, without abdicating your role. Ownership is a gift, but guidance is still a responsibility. The art is in knowing where one ends and the other must begin.

Next time: The Courage to Let Silence Do the Work

How to Listen Without Fixing

Reme Le Hane — Tue, 26 Aug 2025 08:27:00 +0000

I've always been a fixer. My instinct is to protect, to solve, to step in. A close friend once told me I have “White Knight Syndrome” - I never checked if that's really a thing, but it fits. At my core, I want to take away the struggle, to shield others from it.

At the same time, I've always been a good listener. My instinct may be to fix, but I've learned over the years that listening doesn't have to mean acting. It doesn't have to mean rushing in with an answer.

Working as a lead has sharpened this skill. Leadership has taught me the discipline of listening - not to respond, not to solve, but simply to hear and understand. And the more I've practiced it, the more I've realized something: fixing isn't always the solution.

Listening creates space. It lets me sense when someone simply needs to be heard and when they truly need help. And even then, the best next step often isn't jumping in to fix. It's offering. It's asking. It's letting them decide if they want support, or if they just needed to let something out.

This is where relationships matter most. Over time, you learn the difference between a quick vent and a real frustration that needs addressing. You start to see when your role is to clear the path and when it's to simply stand beside them while they walk it.

As leaders, our job is to help our teams be at their best. Some obstacles are visible and easy to remove. Others only come out when someone feels safe enough to share. And in those moments, the best thing we can do is not to fix for them, but to help them fix for themselves. To guide them toward their own solution, to help them own it. Because that's where real growth happens.em toward their own solution, to help them own it. Because that's where real growth happens.

Next time: Guiding Without Owning

The Subtle Art of Asking the Second Question

Reme Le Hane — Tue, 19 Aug 2025 08:04:00 +0000

In 1:1s, whether with my reports or on the rare occasion with my own lead, I’ve noticed something: the safe answer.

You know the one. It’s in response to “How are you doing?” It’s polite. Acceptable. Technically honest — yet designed to sidestep the real truth. I’ve given that answer myself more times than I can count.

The thing is, it’s a perfectly fine question, but it’s also incredibly easy to answer without answering. Over time, once the relationship is built and trust is there, you can often skip straight to the second question. Especially when you can feel that something’s off.

My go-to? A simple, “OK… so how are you really doing?”

It’s not wildly different from the first question, but it carries weight. It signals that you’re paying attention, that you see past the surface, and that you actually care enough to ask again. Often, that’s when a short, guarded answer turns into a 5–10 minute conversation.

It’s also a handy tool when you can sense there’s more to the story, but you don’t yet know enough to ask something more direct.

I’ve been on the other side of it too. My lead has caught me in that safe-answer moment and asked the second question. Sometimes, to my frustration, because those are usually the moments I want to keep my cards close. But in hindsight, those were also the moments I needed that second question most.

Sometimes the first question opens the door.

The second question invites someone to step through it.

Next time: How to Listen Without Fixing

How to Build Teams That Ask Questions Out Loud

Reme Le Hane — Tue, 12 Aug 2025 08:57:00 +0000

A quiet team can feel safe on the surface — no conflict, no interruptions, no awkward moments. But here’s the problem: with a quiet team, you don’t know what you don’t know. When people keep thoughts in their heads, you can miss out on ideas, risks, and opportunities that could change everything.

Some of the best shifts in perspective I’ve seen have come from what others might call “silly questions.” Even the silliest can spark curiosity, trigger a better solution, or help the group see something they’d missed entirely. But those moments only happen if the questions are spoken out loud.

Why teams stay quiet

There are plenty of reasons people hesitate to speak up:
They’re worried about looking unprepared.
They don’t want to slow things down.
They’re unsure if their idea is relevant.
They simply aren’t used to open conversation.

I’ve seen this play out firsthand. You ask a group-level question to a quiet team and get… nothing. But a few minutes later, you ask one person directly, and they talk for five minutes — sharing great feedback and fresh insights you would have never heard otherwise.

How to get people talking

The approach will depend on your team, but one of the fastest ways I’ve found to get ideas flowing is to start “picking” on people. Not in a hostile way, but intentionally choosing someone to respond. Start with someone you know will have an opinion — it gives the rest of the team a chance to think, and often sparks others to jump in.

Even a simple open-ended question like “What are your thoughts?” works better when followed by “Alex, let’s start with you.” It removes the pressure of volunteering and instead gives permission to speak.

Lead by example

One of the most powerful ways to encourage questions is to ask them yourself — especially when you don’t know the answer. During one of my interviews for my current role, I was asked a technical question. I guessed, but made it clear it was a guess. When they told me I was wrong, I simply asked, “What’s the answer?”

That moment mattered. It showed I was comfortable not knowing and more interested in learning than in pretending I knew everything. That’s the kind of behavior I want my team to feel safe modeling.

Make it normal, not exceptional

If you only encourage questions during special “brainstorm sessions,” people will treat speaking up as an exception. If you do it in every stand-up, review, and retrospective, it becomes part of how the team works. The more normal it feels, the more people will share — and the less you’ll risk losing great ideas to silence.

Next time: The Subtle Art of Asking the Second Question

The Tradeoffs of Technical Ownership

Reme Le Hane — Tue, 05 Aug 2025 10:58:00 +0000

Technical ownership sounds great on paper. It means someone cares. Someone is responsible. Someone knows the system inside out.

But like most things in engineering, it comes with tradeoffs.

At a previous company, I was the sole owner of two codebases. I'd been hired to rebuild the mobile app into a new framework-originally React-but after some digging, I realized that plan wasn't going to fly. The company pivoted to rebuilding the management console first and revisiting the app later. Eventually, both became my projects. From the ground up. Just me.

It got to the point where, during a year-end company speech, the CTO half-joked:

“If Reme gets hit by a bus, we're fucked.”

Empowering, right?

It's a strange kind of job security. When you're the only one who understands how things work, you carry a lot of influence. But you also carry a lot of weight. Every bug. Every outage. Every weird edge case in support. Yours. Even when you're not officially on support duty.

Eventually we did hire additional engineers, but that shift came long after the systems had already been shaped by one person's habits, patterns, and shortcuts. That level of individual ownership is efficient in the short term, but risky in the long run.

I've seen this play out in other teams and orgs too:

A single person becomes the go-to. Sometimes they like it. Sometimes they hoard it.

Other times, they're desperate to share it-but no one wants to learn. That's the real danger.

Not just the infamous “bus scenario,” but the slow decay of team resilience and growth.

When ownership becomes isolation, it becomes a bottleneck.

The only strategy I've seen that actually works?

The rest of the team has to care.

Act like a team. Step in. Ask questions. Sit with the owner. Review the PRs. Break the silo intentionally.

Yes, documentation helps. But it only gets you so far. A lot of the critical knowledge is “muscle memory” you don't even think to write down.

I had a moment recently where someone posted a support screenshot. No context. No explanation. Just an error.

But I knew what it was.

A license error in the CI?

That's the wrong environment secret getting pulled. I could trace it in my head without even opening the code.

That's the kind of context you build over time. And the kind that's nearly impossible to transfer through a wiki page.

Technical ownership is powerful.

But without support and shared learning, it quietly becomes a liability.

Next time: How to Build Teams That Ask Questions Out Loud

Why Senior Engineers Don’t Need All the Answers

Reme Le Hane — Tue, 29 Jul 2025 08:25:00 +0000

There's this quiet myth in engineering that once you hit “senior,” you'll just know. You'll have all the answers, solve problems on the fly, and be the go-to for anything and everything.

But here's the truth I've come to learn: I often prefer not to know.

And honestly, I think that's part of why I landed the job I have today.

During my technical interview, I hit a question I didn't quite have the answer to. Or maybe I did, somewhere buried in memory, but it didn't feel familiar enough to stand by. So I said what I genuinely felt: “I don't know.” I took a guess, made it clear that it was a guess, and when it turned out to be wrong, I followed up with curiosity: “So what's the actual answer?” That moment, I believe, said more about how I work than any correct response could have.

Over the years, I've come to value not knowing as a strength. Experience doesn't mean you know everything - it means you've learned how to navigate what you don't. And often, the best ideas, the biggest breakthroughs, and the real “senior” moments come not from brilliance, but from perspective.

That's why I deeply believe there's no such thing as a stupid question. Some of the most “out there” suggestions have changed the entire trajectory of a project or exposed blind spots no one else saw. A half-baked idea can be the thing that nudges a good solution into a great one.

I was lucky early in my career to work with leaders who reinforced this mindset. One of the best mentors I've had was obsessed with improvement. I'd complete a task, call him over, and the conversation wasn't “is it done?” It was: “how can we make it better?” That set a tone I still carry with me - not knowing isn't a failure, it's an invitation to explore.

There's this quiet shift I've noticed that separates junior and intermediate engineers from senior and beyond. It's not the depth of knowledge, it's the comfort with not knowing. The humility to admit it. The willingness to figure it out with others.

I don't recall explicitly mentoring someone on this, but I do talk about it. Just recently, a new team member shared their fear of sounding stupid. I reassured them that if they had a “stupid” question, it might be the best one we hear all day. I try to live that out too - I'll pitch an idea in a team session, then immediately be the first to tear it down. Because being wrong is fine. Ideas don't have egos. If it's a good idea, it'll hold. If not, we move on better informed.

When it comes to giving answers, I try not to - at least not right away. I'll usually ask questions, try to guide a bit. That won't work for everyone, but personally, I learn better when nudged than when told. It just sticks more. There's something powerful in discovering a solution for yourself - you learn more, and you remember more. It becomes your insight, not just someone else's instruction.

Being senior isn't about knowing everything. It's about knowing how to navigate what you don't.

Next time: The Tradeoffs of Technical Ownership

The Problem with Perfect Engineers

Reme Le Hane — Tue, 22 Jul 2025 08:13:00 +0000

Every engineer has their perfectionist phase. I certainly did. There's a season early in your career where every line of code must be beautiful, every edge case handled, every abstraction future-proofed. That desire to do things “right” feels noble - but over time, experience teaches you that chasing perfection is often just a well-disguised form of avoidance.

At some point you realize: perfection is the enemy of done.

That doesn't mean we should write careless code. There's still pride in craftsmanship. But what shifts is your understanding of what done really means. You start seeing the bigger picture - that your work exists in a system with deadlines, dependencies, and a team relying on forward momentum. That no feature will ever be perfect the first time, or even the tenth.

One of the best things about modern software is that it can change. We can patch. We can refactor. We can iterate. (The gaming industry might abuse this a bit - but that's a separate post.)

I once worked with a CTO who, during a boardroom code review, threw a snippet onto the big screen and said, “Who wrote this crap?” Then he checked the git blame. “Oh. It was me. Moving along.”

This was someone with over 40 years of experience, looking at something he wrote six months prior. That moment stuck with me. Even the most seasoned engineers look back on their work and cringe. Not because they were bad - but because they've grown.

That's what makes perfectionism a trap. It assumes you'll have the clarity and knowledge today that only experience can give you tomorrow.

Instead, I've come to embrace something more sustainable: progress with intent. A little bit better each time. There's a great blog post about applying the Boy Scout Rule to code - leave it better than you found it LINK. That mindset lets you move, learn, and improve without getting stuck.

In my own teams, I've learned that perfectionism usually shows up as work taking longer than expected. That doesn't always mean overengineering - sometimes it means someone's struggling and not speaking up. Either way, it's a cue to check in. Especially in remote teams, it's easy to miss the signs until someone's already deep in a rabbit hole.

One thing that helps is writing. Documentation, planning, solution design - not as overhead, but as clarity. When we slow down enough to think clearly up front, we're less likely to drift later.

At the end of the day, managing perfectionism is a skill - one we all have to learn. Sometimes we spot it in ourselves. Other times we need a nudge from a teammate or lead to help us zoom out. The goal isn't to lose that eye for quality - it's to make sure it serves momentum, not stalls it.

Next time: Why Senior Engineers Don’t Need All the Answers