Pierre-Henry @ PierreHenry.Dev

Most systems do not fail because code is hard. They fail because the next change has no clear owner. I build product software around the work that keeps it honest: clear boundaries, one source of truth, failure paths and rollback. I share the decisions, code and mistakes here.

As modern software engineers, we need to guide LLMs in the right direction, understand what our AI agents are doing, and verify that their outputs meet our expectations. And validating their work is just as important as guiding them.

AI is changing how I build software, and how I approach product engineering. Here are my top 3 GitHub projects you should explore today! • Find Skills: It finds and install reusable skills for your AI coding agent. For example, find a skill for code reviews or debugging instead of creating the entire workflow yourself. • Orca: It runs Claude Code and Codex in parallel, each in its own Git worktree. Useful for comparing different implementations of the same feature without mixing code changes. • Playwright MCP: It gives your AI agent access to a real browser. It can navigate your app, fill out forms, click buttons, and check whether user flows actually work. github.com/vercel-labs/skill… github.com/stablyai/orca github.com/microsoft/playwri…

Code is becoming cheaper to generate. Context, architectural judgement and verification aren’t. The next evolution of software engineering isn’t necessarily about replacing Git. It’s about versioning the entire process behind the code: intent, specifications, agent context and proof that the result works. Projects such as Contexo, (which is a brilliant initiative btw), are exploring version control for AI context, while Writ tackles version control and coordination for multi-agent development. Both are early-stage, but definitely worth watching! Git may evolve, or an entirely new layer may emerge. The real opportunity is making AI-generated software reproducible, traceable and trustworthy.

I’m using AI to build software, but I’m not blindly accepting what it generates. I’m questioning the architecture, challenging unnecessary abstractions, and changing the system when the implementation doesn’t fit the actual problem. The goal isn’t to generate more code. The real goal is to build a better product with less complexity.

“We take data privacy seriously!” Until convenience gets in the way. Companies invest in GDPR compliance, secure infrastructure, and access controls, yet sometimes share sensitive data with third-party tools without considering the risks. Data protection isn’t just about where your data is stored. It’s about how you handle it, too. AI is great, but innovation shouldn’t come at the expense of security and privacy. Taking GDPR seriously can prevent costly mistakes and a lot of headaches down the road. Is data protection part of your company’s culture, or just paperwork?

Many products that stop growing don’t have a feature problem. They have a positioning problem. One open source product stayed at the same level for a long time. It grew when the founder found a clear differentiation and told a better story. As engineers, we reach for code first. Sometimes the fix is how we explain what we built.

New ideas usually come from new inputs colliding with old problems. Change what you read, where you go and who you speak with.

Anthropic left Git because of volume, not context: 2,500 → 30,000+ merges/day. By their own words, Scion isn't a general Git replacement. For most FDE work, Git isn't the bottleneck. Keep Git for code. Version intent (specs). Trace agent runs (prompts, models, evals). Prove it works in CI. Fix the process around Git before replacing it.

One thing I’ve learned from working on large production systems is that writing more code doesn’t necessarily mean building better software. I remember working on a platform serving over 250 restaurants. We were experiencing around 8 crashes every week. Of course, we could keep fixing individual issues as they appeared. But would that really solve the problem? Instead, we looked more carefully at the architecture, SQL queries, caching and AWS infrastructure to understand what was actually going wrong. After making the necessary improvements, we went from around 8 crashes per week to zero. And that’s something I believe is particularly important in software engineering, especially today with AI. We can now generate code and implement features faster than ever. But that doesn’t necessarily mean we’re making the right engineering decisions. Before building something new, I always find it important to understand what’s already there. What is actually causing the problem? Can we improve what already exists? Are we introducing unnecessary complexity? And more importantly, will our solution make the product better and more reliable for its users? Sometimes, a relatively small architectural improvement can make a much bigger difference than adding hundreds of lines of code. For me, good software engineering is about understanding the problem, making the right decisions and continuously improving what we build. Not just building more, but building better. Bit by bit.

Useful HealthTech automation needs a clear hand-off. Automate routing, reminders and administrative checks. When input is missing, identity is unclear, data is stale or a dependency fails, create a reviewable task. The goal is less friction, not hidden judgement.

A thought can be loud without being true. Notice it, name it, then decide whether it deserves your belief or your action. 💭

Before rewriting a SaaS platform, I’d first ask what is actually preventing the product from moving forward. In this article, I share the practical checks I use to decide whether a product needs stabilisation, a focused refactor, a component replacement or a genuine rewrite.

As we all know, motivation is unreliable. A small habit with an obvious cue is much easier to rely on when our motivation disappears 👌

AI agents are making code cheaper to produce. But shipping reliable software is still hard. For Forward Deployed Engineers, the real advantage is understanding the business, giving agents the right context, and validating every change against real-world needs. Git versions the code. We also need to version the intent, decisions and evaluations behind it. Less time producing code. And more time solving the right problems and delivering working software!

I’m also pretty sure becoming a Forward Deployed Engineer is the next step in AI engineering! Talk directly to clients. Understand their problems, requirements, and organisation. Build a knowledge base, then let AI tools like Claude Code help you turn that context into a working demo by tomorrow. Get feedback, iterate, and keep improving until the solution delivers real value. Less time translating requirements into code. More time understanding the problem and building the right solution. This is what is happening: → Understand the problem → Build the solution → Deliver real business value!

BRRRR sounds simple: buy, rehab, rent, refinance, repeat. The spreadsheet still needs vacancy, repairs, financing and a bad-case scenario.

A so-called “Forward Deployed Engineer” doesn’t just build software. Of course not! They work close to the users, understand real business problems, and turn them into working solutions. Less theory. And definitely more impact with what you ship! Happy FDE era! 🚢

After years of building software, I’ve learned that progress comes from showing up and making deliberate decisions, not waiting for motivation. Every day, we can ship something, improve what exists, or let things drift. One function. One refactor. One idea tested. Small improvements compound over time. Turning an idea into a real product takes consistency. Build, learn, improve, repeat. More on building and systems thinking: youtube.com/@pH7Programming