ProductOwner.ro

Building an AI Self-Improvement Loop from Claude Code Session History

Fri, 10 Apr 2026 00:00:00 GMT

Building an AI Self-Improvement Loop from Claude Code Session History

The Problem

As a heavy Claude Code user (241 messages/day across coding, documentation, data analysis, and operational tasks), I accumulated 7 months of conversation history — 735 sessions across 30+ projects. That history contains domain knowledge, decisions, corrections, friction patterns, and workflow templates that get re-derived from scratch in every new session.

I've tried organizing this knowledge before: PARA method, skills backlog, retrospectives, video transcript extraction. Every system died from the same three causes: no time to maintain (client delivery always wins), too much friction to use (too many steps to file properly), and no immediate payoff (value is for future-me, but present-me is fighting fires).

The Vision

A system that consumes its own output to improve itself — an ouroboros. Session history feeds knowledge extraction, which feeds better rules/skills/hooks, which produce better sessions, which feed more improvements. The loop must be self-maintaining or it shares the fate of every prior organizational attempt.

Inspired by:

Karpathy's LLM Wiki pattern — raw sources → LLM compilation → queryable markdown wiki
A YouTube implementation extending the pattern for internal session data via Claude Code hooks
Ouroboros — a self-modifying AI agent governed by a philosophical constitution
Phantom — an autonomous AI co-worker with three-tier vector memory (episodic/semantic/procedural), a 6-step self-evolution pipeline with safety gates, and MCP server exposure
Claude Code Karma — open-source dashboard that parses Claude Code's local JSONL session data with production-grade models (7200+ lines of parsers), providing the data layer for session analysis

What We Did in One Session

Phase 1: Problem Space Mapping

Explored 11 of my projects to understand the full ecosystem:

A session dashboard tool with production-grade JSONL parsers for Claude Code data (7200+ lines of parsing models)
An autonomous agent deployed on Hetzner with three-tier vector memory, 6-step self-evolution pipeline, and MCP server
A professional portfolio site showing expertise areas and services
An n8n orchestration PoC (Symfony + n8n + PostgreSQL) showing workflow automation patterns
A skills project with 6 implemented skills, 28 unimplemented feature requests, 3 retrospectives never acted on — the case study of the broken feedback loop
A major client project with 549 Claude Code sessions, 502 git commits, 60+ bug reports, 14 meeting transcripts, 17+ runbooks
An Obsidian vault proving the Karpathy wiki pattern works (13 pages extracted from codebase analysis)

Also examined 4 external references (Karpathy gist, video implementation, Ouroboros agent, 3-year WhatsApp capture vault in capacities.io).

Phase 2: Structured Interview

Used elicitation techniques to uncover:

Daily workflow vision: Open laptop → see what matters today → work human-in-the-loop at 100x speed → fail 200 times → iteration 201 dazzles. "I talked to Gabi and in 2h it was perfect."
Why organizational systems die: No time + too much friction + no immediate payoff. All three must be solved simultaneously.
Compounding returns: Every session makes the next one more efficient. The self-improvement loop isn't a side project — it's core to how I work.
Priority chain: (1) Knowledge capture → (2) Nightly improvement proposals → (3) Morning briefing

Phase 3: Tool Building

Built two tools during the session:

Session Analyzer CLI — A Python script that navigates Claude Code JSONL files using the dashboard's existing parsers. Commands: overview, page N, message N --context, friction, artifacts, subagents. The subagent analysis shows reasoning chains, repeated search patterns, and "hindsight lessons" (what prior knowledge would have made the agent more efficient).

MCP Server from OpenAPI — Used FastMCP to auto-generate 101 MCP tools from the dashboard's REST API. ~10 lines of code. Every endpoint (session timeline, subagent details, tool usage, file activity, analytics) becomes a tool Claude can call natively during any session. Already wired into Claude Code's MCP config.

Phase 4: 100-Session Analysis at Scale

Selected 100 substantial sessions (>50KB) across all projects. Distributed them to 10 parallel subagents, each analyzing 10 sessions using the analyzer tool. Each agent produced an insight report covering: session summaries, domain knowledge, friction patterns, subagent efficiency, improvement opportunities.

Results: ~145KB of insights, 1783 lines across 10 reports.

Cross-cutting findings:

Finding	Frequency
Claude speculates instead of querying actual data	6/10 groups
Subagents spend 50%+ of tool calls discovering file locations	5/10 groups
Friction keyword detector catches only ~20-30% of real events	3/10 groups
Investigation-to-communication iterations equal investigation iterations	3/10 groups
Domain knowledge (entity relationships, API quirks) discovered multiple times, never persisted	4/10 groups

Phase 5: The Critical Insight

The most important finding came from examining what context was active during friction events. When Claude writes technical acceptance criteria instead of behavioral ones, the user-story-writer skill is loaded and explicitly says: "Acceptance criteria are detailed behavioral specifications, NOT test cases." When Claude speculates about root causes, the bug-reporter skill is loaded and explicitly says: "Bug reports are factual documentation, NOT speculation."

The problem is not missing rules — it's a broken improvement loop.

Skills are v1. Users correct Claude in sessions. Those corrections contain the exact before/after data needed to improve the skills. But corrections never flow back into skill updates. So the same friction recurs across sessions.

The self-improvement system must close this gap:

Session friction detected (e.g., "Claude wrote technical ACs")
    ↓
Check what skill/CLAUDE.md was active at that moment
    ↓
Extract the correction (before: what Claude did, after: what user wanted)
    ↓
Propose specific skill amendment using actual correction examples
    ↓
Apply (auto or human-approved) → Skill v2
    ↓
Next session: less friction → validate improvement worked

What's Next

Synthesize the 10 insight reports into a master findings document with prioritized improvements
Build the correction-to-skill pipeline — for each friction event where a skill was active, extract before/after and propose skill amendments
Expand friction detection — current keyword matching misses ~70% of real friction events
Test the MCP server live — 101 tools wired up, not yet tested in a real session
Build codebase navigation maps — reduce subagent search thrashing by ~50%
Set up the nightly improvement job — automated analysis → proposals → morning briefing
Prototype Obsidian vault pages from the 100-session findings

Takeaways for the Community

Your Claude Code session history is a goldmine. Every correction you make, every friction event, every domain fact discovered — it's all in the JSONL files. Mine it.
The Karpathy wiki pattern works for internal data, not just external articles. Session logs = raw sources. LLM compilation = knowledge extraction. Wiki = your compounding knowledge base.
FastMCP + OpenAPI = instant MCP server. If your tool has a REST API, you can expose it as 100+ MCP tools in 10 lines of Python. No hand-coding tool definitions.
10 parallel subagents can analyze 100 sessions in ~5 minutes. The bottleneck is synthesis, not analysis.
The biggest insight isn't about adding more rules — it's about closing the feedback loop. Your skills and CLAUDE.md rules are probably already decent. The problem is that session corrections never flow back into improving them. Build the loop, not more rules.
Every organizational system you've tried died for the same reason: it required your ongoing attention. The self-improvement loop must be self-maintaining or it shares their fate.

Product Drinks Ploiești, Episode 2: Ending an Eventful March

Sun, 29 Mar 2026 00:00:00 GMT

The rain was pouring so hard on this Sunday morning that for a moment I forgot I was heading to Ploiești by train and not commuting somewhere in the Netherlands. The weather hit differently this time, but the destination made up for it.

Back to Ploiești

This was my second time joining Product & Design Drinks in Ploiești and it starts to become a habit. (Here's how the first one went.) The more I visit this small city in Romania, the more it surprises me.

Bülent Duagi introduced us to Teatrul Nației, a place I had never heard of before. Great concept, good food, and they completely conquered my heart with a sticker in the bathroom that said something along the lines of "smoking forbidden. yes, vaping too". That's the kind of attention to detail that tells you the people behind the place care about what they're building.

As always, the atmosphere was laid back. Topics ranged from product development, to AI workflows, to how life in Ploiești actually is, and of course, planning the next gathering. This time, the plan is a wine-tasting oriented location since spring is expected to bring better weather. I'm already looking forward to it.

The conversations that matter

Besides the fun times, these kind of get-togethers bring real professional value. You get to sit down with people who think about similar problems and learn from how they approach things.

I had a chance to hear from Andrei Stroescu and Catalin Stanciu about how they are tackling product challenges and orchestrating their AI workflows. The kind of conversation you can't get from a webinar or a LinkedIn post.

I also met Georgiana Atanasiu, who pivoted from CRO to Product. We had a lot to talk about, especially around Omniconvert and the cool things she was doing back in the day. She also recently attended the LIT Hackathon where she tackled a last mile delivery challenge from Sameday. That kind of problem felt like it would be perfect to model in Machinations.io, where you put all your variables into a scenario and run simulations until you find the highest throughput for parcel delivery, similar to what game designers do for game economics. Food for thought. And an even bigger FOMO for me for not making it to that hackathon in time.

An eventful March

March 2026 has been packed. My energy levels were not always there, and I was not fast enough to write about everything as it happened. But the events themselves were worth showing up for, and I plan to give each of them the dedicated write-up they deserve.

Here's what my March looked like:

Mar 2 - AI x Business #1: Using AI at Sameday. Dragoș Bărbulescu shared concrete use cases and lessons learned from actual AI implementations at Sameday. The chat was on fire with discussions about adoption metrics vs usage metrics. Read my writeup.
Mar 3 - How AI is changing product decisions at Booking Holdings in Bucharest. A fireside chat with product leaders from Booking.com, Clever Craft, and Trilogy. One of those rare in-person events where the networking afterwards is just as good as the panel. Read my writeup.
Mar 6 - AI Talk: Cursor for non-coders. Radu and Tibi explored how Cursor works as a workspace for thinking and execution beyond coding. Cold email personalization, competitor analysis, prompt optimization. Read my writeup.
Mar 13 - AI Talk: Mentorship program automation with n8n. A live session on how the Product Mentoring Programme automates operations for 30+ mentors and 300+ mentees through n8n workflows. Read my writeup.
Mar 13 - Change management strategy and vision. A session with Paula Anastasiade moderated by Bülent. This one hit close to home. I first encountered change management around 2013 when I worked with process mapping consultants, and I've been trying to master it since. I even proposed a follow-up session: horror stories from change management gone wrong, part standup comedy, part group therapy. Bülent is already thinking about a dedicated series. I volunteered. Read my writeup.
Mar 19 - Upskilling the Romanian IT Industry at ING Hubs. A hands-on session about turning soft skills into power skills in an AI-driven landscape. I asked some spicy questions there about role blending in the age of AI. Read my writeup.
Mar 25 - Claude Community Bucharest: Meet the Builders. The inaugural gathering of the Claude AI community in Bucharest. 240 people showed up. Live demos of Claude Code and the Claude API for AI agents. The energy was real. Read my writeup.

What I take from all of this

When I look at this list, the common thread is obvious. AI is everywhere, but the events that stuck with me were the ones focused on the human side: how we adopt, how we change, how we show up and talk to each other about what we're building.

Ploiești was the perfect ending for this kind of month. No slides, no agenda, just good people, good food, and the kind of conversations that make you leave with more questions than answers. In the best way possible.

Thanks to Bülent for bringing this community together, and to everyone who made March such a rich month. See you at the wine tasting.

Claude Community Bucharest: 240 Builders Walk Into a Zoom Call

Wed, 25 Mar 2026 00:00:00 GMT

I had just ended a long day at work when the Zoom link went live. It was a Tuesday evening, I had no plans to be productive, and then 240 people showed up to talk about Claude. So much for an early night.

What happened

Claude Community Bucharest held its first ever gathering. An online meetup organized by Alex Bordei (Senior Software Engineer) and Andrei Marmureanu (eCommerce Automation Expert). The format was straightforward: live demos of Claude Code and the Claude API for building AI agents, followed by Q&A.

Two builders who use Claude decided Bucharest needed a community around it, so they made one. That's it.

Why 240 attendees matter

Let me put this in perspective. Getting 240 people to show up for the first edition of anything is hard. Getting them to show up for a community-driven event about a specific AI tool, with no celebrity speakers and no giveaways, is a signal.

The Romanian tech scene has always been strong on the engineering side. What's new is how quickly people are moving from "I tried ChatGPT" to "I'm building agents with Claude's API." That gap used to take years. Now it takes months, sometimes weeks.

I'm biased here. This entire website is built and maintained with Claude Code. Every blog post, every layout change, every deployment fix. I've been using Claude daily for my product work long before this community existed. So watching a local group form around the same tool I already depend on felt like finding out your favorite obscure band just sold out a venue.

What I take from this

Bucharest has always had the talent. What it sometimes lacked was the connective tissue between individual builders doing interesting things in isolation. Communities like this one create that tissue. They turn "I figured this out alone at 2 AM" into "here's how three of us solved the same problem differently."

I'll be watching this one closely. And probably showing up late again.

Thanks to Alex and Andrei for putting this together. Building a community from scratch takes guts. 240 people on night one says you're onto something.

The AI Superpowered Agile Professional

Thu, 19 Mar 2026 00:00:00 GMT

I typed a joke in the chat during the Agile Minds Romania session. "Any funny stories about AI adoption? Like a VP sending their AI companion to join the meeting on their behalf?" I was going for laughs. Instead, Vlad casually confirmed this is already common practice. His personal agent brings him meeting notes for meetings he can't attend because he's triple-booked.

My joke was already yesterday's news.

The session featured İnanç Jivaş and Gözde Toker-Kumbasar, moderated by Florin Manolescu and Mihai Olaru. I couldn't use my mic, so I lived in the chat. Three things stuck with me.

Agile + AI + Change Management

İnanç presented a framework: the intersection of Agile, AI, and Change Management is what makes organizations future-ready. Sounds like a LinkedIn headline, but the argument is solid.

venn-beta
  set AI["AI"]:100
  set Agile["Agile"]:100
  set CM["Change Mgmt"]:100
  union AI,Agile:20
  union AI,CM:20
  union Agile,CM:20
  union AI,Agile,CM["★"]:5
  style AI fill:#3b82f6, fill-opacity:0.7, stroke:#2563eb, stroke-width:2, color:#fff
  style Agile fill:#10b981, fill-opacity:0.7, stroke:#059669, stroke-width:2, color:#fff
  style CM fill:#f59e0b, fill-opacity:0.7, stroke:#d97706, stroke-width:2, color:#fff
  style AI,Agile,CM fill:#4f46e5, fill-opacity:1, color:#fff

★ = future-ready, human-centered, adaptive organizations.

AI without agile becomes shelfware. Agile without AI falls behind. Both without change management fail at adoption. I've seen all three failure modes. Diagram is my own interpretation, not İnanç's original slide.

Productivity vs. capability

I asked whether they feel more productive using AI. Gözde's answer stuck: she doesn't frame it as "more productive" or "more fast." She frames it as more capable. AI gave her the ability to notice patterns in her daily work she was blind to before. That shifts the question from "am I faster?" to "can I do things I couldn't do before?"

Roles are blending

I asked: "Do we still have boundaries between roles, or is everybody doing everything now?" İnanç's response: intelligence is becoming a commodity. If AI writes the code, it doesn't matter whether a developer or a product manager prompted it. What matters is critical thinking.

Gözde added that our roles are evolving from executors to pattern interpreters and meaning-makers. You're not being replaced by AI. You're being promoted from doing the work to deciding what the work should be.

Thanks to İnanç and Gözde for a session with more substance than most AI panels. And thanks to Vlad for confirming that my jokes have a shorter shelf life than I thought.

From Soft Skills to Power Skills: What Happened at ING Hubs

Thu, 19 Mar 2026 00:00:00 GMT

First slide of the evening at ING Hubs Romania and it's a Hofstede Cultural Dimensions chart comparing Germany, Romania, the UK, and the US. If you haven't come across Hofstede before, the idea is simple: every country has measurable cultural traits that shape how people work together. How comfortable are they with hierarchy? How much do they value individual achievement over group harmony? How do they handle uncertainty?

Romania scores 90 on Power Distance (we're very comfortable with hierarchy) and 90 on Uncertainty Avoidance (we really don't like surprises). Meanwhile, we score just 20 on Indulgence, which roughly means we lean toward duty over enjoyment. Compare that to the US with 40 on Power Distance and 68 on Indulgence, and you start to see why Romanian teams and American clients sometimes feel like they're speaking different languages even when the English is perfect.

The reason this chart matters: Germany, the UK, and the US are the countries that bring IT business to Romania. They decide if we're good executors or if we're more than that. And these cultural gaps are exactly where "soft skills" stop being soft and start being the difference between a delivery team and a strategic partner.

The event

Upskilling the Romanian IT Industry was a working session on March 19, 2026, at ING Hubs Romania in Bucharest. The premise: transforming soft skills into "power skills" through practical application. A panel discussion on professional capabilities in today's AI-driven landscape, followed by interactive workshops and networking. Speakers: Anne Dumitrache (Trainer, Coach and Organizational Psychologist), Alin Pandichi (IT Area Lead at ING Hubs Romania), Silvana Helal (Digital Transformation Leader at Human Leap), and Răzvan Căciulă (VP of Engineering at Showpad). The kind of event where you actually talk to people face to face, which apparently still matters.

Burnout vs. smart work

One of the tracks tackled something I see everywhere: the swing from overwork culture to the disengaged 9-to-5 mentality. Two extremes, neither productive. Add the AI revolution creating constant pressure for continuous learning, and you get a recipe for burnout, stress, and loss of intrinsic motivation.

The learning goal was straightforward: sustainable high performance. Build resilience. Shift from external motivation (bonuses, promotions, fear) to intrinsic motivation (purpose, mastery, autonomy). Simple to say. Brutally hard to do. But at least naming it correctly is a start.

Self-leadership without the title

The second track that caught my attention was about self-leadership and strategic vision. The key issues were painfully familiar: over-reliance on managers, lack of proactive ownership, fear of stepping forward without formal authority. This is the Romanian IT industry in a nutshell. We wait for someone to tell us what to do, then complain that nobody listens to our ideas.

The goal was to understand self-leadership as an individual contributor. Practice initiative, accountability, and influence without needing a title on your business card. I liked the framing. You don't need to be a manager to lead. You just need to stop waiting for permission.

The hero self and the traumatized self

There was a flipchart with a Venn diagram showing True Self, Traumatized Self, and Hero overlapping. The discussion around it was fascinating. The "hero self" for Romanians means not trusting authority. Which, given our history, makes perfect sense. But if we wear this mask too long, it becomes our identity.

And then someone dropped the most Romanian insight of the evening: "The most damaging thing for Romanians: what will people say?" I felt that one in my bones. We optimize for perception instead of progress. We avoid risk not because the risk is real, but because someone might judge us for trying. It's a cultural trap that keeps smart people playing small.

VUCA is dead, welcome to BANI

Apparently we've graduated from VUCA (Volatile, Uncertain, Complex, Ambiguous) to BANI: Brittle, Anxious, Non-linear, Incomprehensible. The key shift is the "non-linear" part. You can't establish cause and effect anymore. Something happens in one corner of the world and your sprint planning falls apart for reasons nobody could have predicted.

I don't love acronyms, but BANI at least feels honest. "Anxious" is a better description of the current moment than "uncertain." Uncertainty implies you might figure it out. Anxiety implies you know you won't.

Resilience is entrepreneurship in disguise

One definition of resilience stuck with me: "Resilience means that you will invest effort in something that might not happen." That's not just resilience. That's entrepreneurship. That's every side project, every product bet, every decision to learn something new when you have no guarantee it'll pay off.

The adjacent topic was self-regulation. How do I regulate my emotions in this crazy world? No easy answers were offered, which I appreciated. Anyone who gives you a three-step framework for emotional regulation in 2026 is selling something.

Executive presence in one sentence

Someone defined executive presence as "reading a room." That's it. Not the power suit, not the deep voice, not the MBA vocabulary. Reading a room. Knowing when to speak, when to listen, when to push, when to back off. I've seen junior developers with better executive presence than C-suite executives. It's a skill, not a rank.

The panel: patience, critical thinking, and ethics

During the panel discussion, we tackled the question: "Technical expertise is no longer enough on its own. Which soft skills are becoming critical for people in technical roles today?"

My answer was patience. I know it sounds boring. But patience is what lets you sit with ambiguity instead of rushing to the wrong solution. Patience is what lets you listen to a user's actual problem instead of jumping to the feature you already wanted to build. Patience is the skill that makes all other skills work.

Alin's answer was sharper: problem framing and critical thinking, especially the ability to filter the flood of AI-generated information. He also said something I wrote down immediately: "Soft skills are like muscle. They grow when you're using them." Not when you read about them. Not when you attend a workshop. When you actually practice them in the messy, uncomfortable, real world.

Răzvan brought up the ethical aspects of technology, which was a welcome addition. We spend so much time talking about what AI can do that we forget to ask what it should do.

The harder questions

The panel also wrestled with: "How can we assess and track the development of these skills? Do you believe frameworks such as OKRs, KPIs, or other evaluation methods can meaningfully capture progress in communication, collaboration, or emotional intelligence?"

And: "Where do you think people and organizations currently stand compared to the level that will be required?"

I don't think we landed on clean answers. Which is the point. If measuring soft skills were easy, we'd have solved it decades ago. The fact that we're calling them "power skills" now is at least an acknowledgment that they're not secondary to technical skills. They're what makes technical skills useful.

What I'm taking home

The Hofstede chart at the beginning set the tone perfectly. Romania's IT industry exists in a web of cultural expectations set by Germany, the UK, and the US. We can either keep being "good executors" who deliver what they're told, or we can develop the power skills that let us shape what gets built, not just how it gets built.

Resilience, self-leadership, executive presence, emotional regulation, patience. None of these show up on a Jira board. All of them determine whether your Jira board matters.

Good event. Good people. Good conversations that didn't end when the panel ended. That's the part you can't replicate on Zoom.

Change Management: Horror Stories and Hard Truths

Fri, 13 Mar 2026 00:00:00 GMT

Watch the full session

Back in 2013, a consultant I was working with dropped a line that rearranged something in my brain: if you don't do change management properly, everyone will end up hating each other equally. I've been trying to get better at it ever since.

Paula gets it

When Bülent Duagi announced a session on change management strategy and vision with Paula Anastasiade, I signed up immediately. Paula brings over a decade of change management experience across multinationals in IT, tech, and FMCG — the kind of person who knows which transformations actually stick and which ones collapse under their own weight.

Paula covered the foundations: what change management actually is (not just adoption, but whether people can use the solution consistently as it was designed), the role of sponsors and leaders, and the critical difference between vision, strategy, and narrative. Vision is what future we're building through change, strategy is how we get there, and narrative is how we communicate both. Simple framework, but the kind of simple that takes years of experience to distill.

The elephant in the room: upper management

The question nobody loves to ask out loud: what do we do with upper management who doesn't see the value of change management?

In many organizations, especially in Romania, the people with decision-making power treat change management as an optional extra. Something you do if there's budget left over, not something you plan for from day one. Paula and Bülent addressed this head-on: the community is fragmented, there's no unified standard, and what change managers are typically taught has limited applicability in AI and digital transformation contexts.

What resonated most was the idea of magical thinking at the top: leaders who assume that because they understand the change, the understanding automatically downloads into everyone else's mind. If you've ever worked in a company where the CEO announces a major transformation in an all-hands and then expects adoption by next quarter, you know exactly what I'm talking about.

Making the cost of doing nothing visible

One approach that came up in the chat: frame change management as a financial risk, not a nice-to-have. If you think it's expensive to sit down and talk about what might go wrong with this change, wait until you see the bill for not doing it.

The challenge is sustainability. Keep raising uncomfortable questions and you risk being tuned out, especially when your perspective differs from the room. Navigating that balance between honesty and political capital is its own skill.

The AI fear nobody wants to name

The conversation inevitably shifted to AI. Not "AI will change how we work" in some abstract sense, but the raw, visceral fear of obsolescence. That's what keeps people up at night, and that's the kind of change that needs the most careful management. You can have the best AI implementation strategy in the world, but if your people think the end goal is to replace them, good luck getting their buy-in.

Horror stories and group therapy

An idea that came up during the session: a future meetup built around horror stories from change management experiences gone wrong. Part comedy, part group therapy. The reception was immediate — Cristina said one session wouldn't be enough, Bülent might create a dedicated series, and I volunteered to help make it happen. Preferably at Dealu Mare with some fetească neagră, because tongues loosen up after a couple of glasses :D

The best learning I've ever done came from hearing about things that went wrong. Every product owner, every change manager, every leader has at least one story where they thought they were doing everything right and it still blew up. Those stories, told honestly, are worth more than a hundred best-practice presentations.

The bits that stayed with me

A few things from the discussion that stood out:

Leaders hiding behind fear. Leaders afraid of their people's reaction to change prefer to hide information, which only creates more rumors and gossip. The very thing they're trying to avoid, they're creating.

Starting from reality, not textbooks. Build on the organization's actual level of maturity, resources, and context — not on what the framework says they should do.

Change management as a portfolio. When you have a system migration running simultaneously with a restructuring and an AI rollout, each change competes for the same people's attention and emotional bandwidth. Managing them as a portfolio minimizes collisions.

What I take from all of this

As a product owner, the hardest part of my job is not the product decisions — it's getting people aligned around change. Building the right product means nothing if the organization can't absorb the change that product introduces. Paula's session reinforced that conviction and gave me better language to talk about it.

Looking forward to the next session. And if the horror stories meetup happens, I'll bring the wine.

Thanks to Bülent for moderating and to Paula Anastasiade for a session that was both practical and thought-provoking. If you want to join future Product Makers sessions, follow the community. And if you have a change management horror story, keep it warm. We might need it soon.

How an MCP Server Turned n8n from Frustrating to Fast

Fri, 13 Mar 2026 00:00:00 GMT

Watch the full session

I was sitting in the audience of a Product Makers Romania live session, watching Adi build an automation workflow in real time, and the moment that got me was not the workflow itself. It was when he dictated a prompt into Claude Code, Claude read the existing workflow through an MCP server, and spat out a new one in seconds. No copy-paste. No downloading JSON files. No switching tabs. Just "go look at that workflow and make me a new one without the Slack part."

The setup: 30 mentors, 300 mentees, and a lot of forms

The Product Mentoring Programme is not small. We are talking 30+ mentors, 300+ mentees, 12 tracks, and a team of volunteer organizers who need to know what is happening without drowning in admin work. The session was Adi walking two new organizers, Ioana and Diana, through the n8n workflows that keep the whole thing running.

The core flows are deceptively simple on paper. A mentor fills out a form on QuestionScout. The form submission triggers a webhook. The webhook pushes data into a Google Sheet. Twice a day, a scheduled trigger reads the sheet and sends a summary to Slack. That is it. Mentor signup, done.

But "that is it" hides the interesting parts.

The manual mapping problem nobody warns you about

Here is what I appreciated about this session: Adi did not hide the ugly parts. He showed the field mapping step where you have to manually connect each form field to a spreadsheet column. He tried the automatic mapping, it pulled in a ton of noise he did not want, so he switched to manual. One field at a time. Name, email, phone, LinkedIn, expertise, topics, photo, introduction, submission date.

It is tedious. It is the kind of work that makes you question your life choices. And it is exactly the kind of thing nobody shows in a polished demo.

He also showed a trick he learned from Georgiana, a QA person in the programme: pin your test data. Instead of filling out the form every single time you want to test a step, you pin the webhook output and reuse it. He said he wasted hours before learning this. I believe him. I have been there with different tools, different contexts, same frustration.

The MCP moment that changed everything

Adi was transparent about his history with n8n. He started using it in August last year, and it was rough. Copy-pasting between Claude and n8n, taking screenshots of errors, manually downloading JSON workflow files to give Claude context. He described hitting a wall where he simply could not make progress.

Then he discovered the n8n MCP server. Game changer. His words, not mine, but I agree with the assessment.

With the MCP connected, Claude Code can read workflows directly, understand the node structure, create new workflows, update existing ones, and debug problems without Adi having to be the middleman shuttling information back and forth. He showed it live: asked Claude to describe an existing workflow, then asked it to create a simplified copy. It worked. The new workflow had the same webhook configuration, the same field mappings, ready to go.

The friction reduction is the point. Adi said he spent 8 hours on a flow with the MCP that would have taken 3 days without it. Not because the MCP is magic, but because it eliminates the thousand paper cuts of context-switching between tools. Death by a thousand paper cuts, as he put it. I use that exact phrase for half the problems I solve at work.

The badge generator: where it gets fun

The more complex workflow was the badge generator. When a mentee completes the programme, they get a personalized badge they can post on LinkedIn. The flow goes: QuestionScout form, extract data, look up the mentor mapping in a spreadsheet, build a payload, send it to RenderForm API, download the generated image, rename the file to something human-readable (instead of a random hash), split the output to both email it to the mentee and upload it to Google Drive, and log everything to an audit sheet.

And none of the code was written by Adi. Claude wrote the JavaScript nodes. Claude built the formatting logic for Slack messages. Claude handled the LinkedIn URL normalization when someone forgot to include https://. Adi's job was to describe what he wanted and debug when things broke. That is product thinking applied to automation. You define the outcome, the tool figures out the implementation.

LLMs as amplifiers, not replacements

The best line of the session came when someone asked about what skills matter in this world. Adi's answer was blunt: LLMs are amplifiers. If you cannot explain what you want to Ioana and Diana, you will not be able to explain it to Claude either. If you communicate well with humans, you will communicate well with AI. The reverse is also true.

He mentioned using WhisperFlow to dictate his prompts, and being embarrassed at first because his spoken thoughts were messy and repetitive. But then he would tell Claude to "play it back to me" and see how well it structured his rambling. That is a workflow I have stolen for my own use. Thinking out loud into a dictation tool, then letting the LLM organize it, is genuinely better than trying to type perfectly structured prompts.

Why n8n and not just Claude Code for everything

Someone asked this directly: why not do everything in Claude Code or Cursor? Adi's rule is practical. If it is something only he runs, even if he runs it 15 times, he keeps it in Claude Code. If other people depend on it and it needs to run without his laptop being open, it goes to n8n. The mentoring programme workflows need to run 24/7 regardless of whether Adi is at his desk. That is the whole point.

He even showed a personal example going the other direction. He had a client time-tracking workflow in n8n that reads color-coded calendar events and generates billing summaries. It worked, but he was already living in Claude Code all day, so he rebuilt it as a Claude Code skill. One less browser tab. One less context switch. The right tool for the right context.

The real takeaway

The session was not really about n8n. It was about how much faster you can move when you reduce the friction between your intent and the tool that executes it. MCP servers are the current best answer to that friction for workflow automation. They let the LLM see what you have built, understand it, and modify it without you being the translator.

Adi ended by asking Ioana and Diana how ready they felt on a scale of 1 to 10. Ioana said 8. Diana said "10, but I feel ready to break some things." That is the best answer. You are never ready to use a new tool until you are ready to break it.

I walked away wanting to connect more of my own tools through MCP servers. Not because it is trendy, but because I have felt that same copy-paste friction Adi described, and I know how much time it eats.

If you are running community operations manually, look into n8n with an MCP connection to your LLM of choice. The setup cost is real, but the iteration speed after that is something else entirely. And if you are presenting your automation work, do it like Adi did: live, messy, with real data and real mistakes. That is how people actually learn.

Cursor for Non-Coders: CSV Wrangling, Ad Scraping, and Arguing With Yourself

Fri, 06 Mar 2026 00:00:00 GMT

Watch the full session

I wrote about a workflow for turning meeting transcripts into structured requirements using AI. Record the kickoff, transcribe it, extract decisions and action items, iterate. So when Product Makers Romania hosted a session called "Cursor for Non-Coders," the premise felt familiar. One speaker took that same idea further: he drops a transcript into Cursor, chains it through a strategy memo template, then runs the output through a Devil's Advocate framework. No code written. Just structured thinking inside a code editor.

10,000 rows of garbage data and a cold email dream

Radu went first with a use case that had nothing to do with writing software. He had a marketplace business (think EMAG, but only the marketplace side) with about 50 companies and 1,000 customers. Classic chicken-and-egg problem. He needed to onboard more companies to make the marketplace attractive, and he had a list of 10,000 potential companies to reach out to.

The catch? The data was a mess. Three different columns for the owner's name, with values swapped between them. Company descriptions that read like someone's autobiography. Some fields in French. Some fields empty. The kind of CSV that makes you question your life choices.

What he did next was beautifully iterative. He fed the CSV into Cursor, asked it to add the columns he needed (first name, core offering, target segment, promo URL), and then went step by step. Extract first names, but handle "Dr. James Chan" correctly instead of just grabbing the first word. Deduce core offering from verbose company descriptions. Translate French entries to English. Batch API calls in groups of 50 to keep costs down. After each step, he exported the CSV, opened it in Google Sheets, eyeballed it, and went back with corrections.

No code review. No folder structure. He didn't even look at the code Cursor generated. He just talked to it, checked the output, and iterated. Nine steps later, he had 3,200 clean, personalized contacts. He loaded them into his cold email tool, sent the sequence, and 33 companies signed up. That's a 1% conversion rate, which sounds small until you realize those 33 new companies drove 19% of sales in the first week. Average order value went up 2% too, which on his actual business model (not the EMAG analogy) was significant.

The part that stuck with me: he said at the end, when he looked at the actual code Cursor had written, it was a mess. V1, V2, V3 files everywhere, no organization. But it didn't matter, because the output worked. That's a fundamentally different relationship with code than what developers have. And it's valid.

Scraping LinkedIn Ads without paying for a SaaS

Radu's second use case was competitive intelligence. He wanted to study a competitor's LinkedIn ad strategy, so he pointed Cursor at the LinkedIn Ad Library. The usual browser extensions didn't work (LinkedIn probably sent them a cease and desist). So he had Cursor build a scraper using Playwright, a headless browser that scrolls through pages, clicks "Load More" buttons, and extracts everything: ad copy, CTA, creative URLs, impression ranges, run dates, advertiser info.

He used Granola as the example competitor for the demo, but the real project had 2,100+ ads to analyze. From the scraped data, he could identify which ads ran longest, which had the most impressions, and reverse-engineer the competitor's messaging strategy. All without buying an enterprise SaaS tool or getting budget approval for a 10K/year subscription.

When someone asked if he could have done this without Cursor, his answer was honest: probably, but it would have been slower, more expensive, or involved a lot of copy-paste into Excel. The tool removed friction, not complexity.

Cursor as a thinking partner (not a doing partner)

Tibi took a completely different angle. He's a product manager in healthcare, coming from fast-moving startups, and his problem wasn't automation. It was thinking.

His workflow starts with a folder of context files: meeting transcripts, survey results, Jira exports, company strategy docs. Then he has a collection of reusable markdown files, each one a set of instructions for a specific task. Strategy memo template. Devil's advocate framework. Executive summary format. Engineer perspective review. Base/bear/bull case analysis.

The magic is in how he chains them. He drops a transcript from a kick-off meeting with his Head of Product, then tells Cursor: "Take this transcript, run it through the strategy memo template, create a file." Cursor reads both files, extracts the key points, and produces a structured one-pager. Then he says: "Now take that memo and run it through Devil's Advocate." And suddenly he has a document that systematically argues against his own strategy, poking holes in assumptions and highlighting risks.

He does this before walking into leadership meetings. Instead of getting caught off guard when someone spots an obvious gap he missed, he's already stress-tested the argument. The tool isn't writing for him. It's arguing with him.

I liked his framing: "You can only mess up so many times before people stop believing you when you try to say something with confidence." Cursor helps him be less wrong before he opens his mouth.

Why markdown files and not built-in features

Someone asked Tibi why he uses plain markdown files instead of Cursor's built-in skills feature. His answer was portability. When he started, skills didn't exist yet. But even now, he wants to be able to grab his files and move to Claude, or whatever becomes better next week. Every LLM understands markdown. No vendor lock-in.

He also made a point about metaprompting: if you hear a good framework on a podcast or read one in a book, you can ask Cursor to turn it into a reusable markdown prompt file. He gave the example of hearing about "base case, bear case, bull case" analysis in a finance newsletter and asking Cursor to create a product management version of it. Ten minutes later, he had a new tool in his toolbox.

There's something genuinely clever about building a personal library of thinking frameworks as executable prompts. It's like a second brain, except this one actually talks back.

The part where AI gets too enthusiastic

The funniest moment was when Tibi told the story of Cursor hallucinating a "Forest Score" metric. He was building a prototype for a dashboard that tracked branches (as in office branches). Cursor apparently went from "branch" to "tree" to "forest" and invented an entire metric around it. Complete with confidence.

A participant from the audience confirmed the same problem: the tools try to be too autonomous. They load skills you didn't ask for, generate files you didn't request, and run up costs doing things nobody wanted. Tibi's solution was practical: his markdown files include explicit instructions like "don't generate images," "don't create applications," "we're only thinking here." Boundaries matter.

Pick one tool and go deep

I shared my own take during the session: I chose Claude Code, and I'm sticking with it. There's too much to learn if you try to master everything. Every week there's a new release from Cursor, Claude, OpenAI, Gemini. You'll drown in FOMO if you chase all of them.

Tibi agreed but added nuance. For thinking and document work, he prefers Cursor. For prototyping, Claude Code feels better. For speed (with more errors), OpenAI's Codex. You won't discover your preferences without trying, but you also won't get good at any of them if you spread yourself too thin.

The real skill isn't mastering any particular tool. It's context management. Knowing what information to give the AI, how to organize it, and when to hold back. We're all becoming context managers now, whether we like it or not.

This was the second AI Talk in the Product Makers Romania series, after the Claude Code session in January. Tibi shared his 18 reusable prompts for anyone who wants to try this workflow. If you're a PM who hasn't opened a terminal or an IDE yet, this might be the gentlest on-ramp I've seen. Just don't let it invent forest-related metrics without your permission.

How AI Is Changing Product Decisions: A Fireside Chat at Booking Holdings

Tue, 03 Mar 2026 00:00:00 GMT

Ady Rugina is the person who introduced me to Claude. I later returned the favor by showing him Claude Code. We've been bouncing ideas off each other ever since — he's one of those people whose thinking I genuinely respect, part mentor, part sparring partner. So when I heard he was speaking at a fireside chat in Bucharest about how AI is changing product decisions, there was no question I'd be there.

The panel you didn't expect

The event was organized by Product Makers Romania and Booking Holdings Romania, hosted at their U Center office on Calea Serban Voda. Over 60 product professionals showed up on a Tuesday evening. The format was a fireside chat moderated by Albert Cristea (Director of Products at Clever Craft), with three panelists who couldn't have come from more different product worlds:

Vaibhav Shrivastava, Head of Supplier Fraud at Booking.com
Ady Rugina, Product Consultant and Creator of Tinker w/ AI
George Dita, PM of Mergers & Acquisitions at Trilogy

Fraud prevention. M&A. Consulting. Three completely different contexts, all trying to figure out how AI changes the way they make product decisions. That's what made this panel worth showing up for. It wasn't another "AI will change everything" talk. It was people from specific, unglamorous corners of product work sharing how AI actually shows up in their day-to-day.

What the speakers actually said

The panel tackled the top-voted questions from the audience, and the conversation went far beyond roadmaps and hype. Here's what stuck with me.

Product is the new bottleneck. AI is accelerating development at a speed that's exposing how slow product decisions can be. Roles are merging — PMs are expected to vibe-code, developers need a stronger product mindset, and the middle management layer is thinning as stakeholders execute on their own. As Vaibhav put it: "As development is moving at an unprecedented speed... we (Product) are becoming the new bottleneck."

Bad AI output usually means bad context. In many cases, poor AI results come down to how we use the tools. Either we don't provide enough context, or we force AI to follow workflows designed for a pre-AI world instead of focusing on outcomes. George nailed this: "Don't try to force existing, non-AI, processes into a new AI workflow or solution."

Industry knowledge is your competitive advantage. George shared a thought-provoking take: "Creativity isn't evenly distributed among individuals; it does not follow a clean normal distribution... like intelligence does." When AI tools are widely accessible, what differentiates people is pattern recognition and deep domain knowledge. Vaibhav added that "while we were working with ML and statistical models before LLMs, AI has now been an absolute game-changer for complex fields like fraud detection and prevention."

Succeeding means learning to unlearn. To thrive in this new reality, we need to let go of some of the ways we work today. It means actively choosing to be at the forefront of this transformation rather than being left behind by it. Ady summarised this mindset best: "Learn continuously... use the tools at a level that makes you uncomfortable."

The part after the panel

The formal Q&A ran until about 8 PM, and then came the part I actually look forward to most at these events: networking. The conversations that happen during these sessions are consistently more valuable than anything said on stage. Not because the panel wasn't good. It was. But because one-on-one conversations let you go deeper, ask the dumb questions, and find out what people actually think versus what they say with a microphone in front of them.

This is also why in-person events still matter. I've attended plenty of webinars and virtual panels. They're fine. But they don't give you the hallway conversations, the "oh wait, you work on that too?" moments, or the simple act of sharing a table with strangers who turn out to be dealing with the same problems you are.

Showing up is the strategy

March 2026 was shaping up to be a packed month for me (and it delivered), but this event on the 3rd set the tone early. It reminded me that the best way to stay sharp in product is not reading another framework article on LinkedIn. It's showing up, listening to people who think differently, and staying curious about how the same technology lands in completely different contexts.

If Product Makers or Booking Holdings organize something similar again, do yourself a favor and go. Even on a Tuesday evening. Especially on a Tuesday evening.

Thanks to Vaibhav, Ady, and George for a brilliant fireside chat, and to Booking Holdings for hosting. Extra kudos to Albert for the facilitation and to George for his thought-provoking contributions.

AI x Business #1: Adoption Metrics, Not Usage Metrics

Mon, 02 Mar 2026 00:00:00 GMT

A fifty-minute session that nobody wanted to end. People apologizing for having to leave because their next meeting was starting, but clearly wishing they could stay. That's how the first AI x Business went.

What this was

AI x Business is a new online series organized by Bülent Duagi and Leonard Alexandru under the Product Makers umbrella. Twenty minutes of presentation from someone doing real AI work inside a real company, followed by thirty minutes of Q&A. No pitch decks. No roadmap slides.

The first edition featured Dragos Barbulescu, VP of Technology at Sameday, talking about how they actually use AI. Actual implementations, with the scars to prove it.

The stuff that stuck

Adoption metrics vs usage metrics. Don't measure how many people opened the tool. Measure how many people changed their behavior because of it. Usage is vanity. Adoption is signal. This distinction alone is worth the price of admission.

Small fixes that cascade upstream. Small efficiency gains in sub-processes that ripple upward and improve entire workflows. I've seen this play out in every eCommerce project I've worked on. You fix something small, like how returns are processed, and suddenly the whole customer service team breathes easier, which makes the operations team's life better, which eventually shows up in the numbers management cares about. The trick is having the patience to start small and the faith that the cascade will happen.

Removing gatekeepers, not people. The best AI implementation inside a company doesn't replace people. It removes the barriers between them and the work they want to do. People who previously needed someone else's permission or expertise to get things done can now just do them. That's the promise worth chasing.

The innovation-speed tension. You need to innovate, but you also need to move in a timely manner. Every engineering leader I've worked with lives in this tension daily. Hearing someone from Sameday acknowledge it openly felt refreshing.

Why the chat mattered

In most online events, the chat is an afterthought. This session was different. People were building on each other's ideas in real time, pushing the discussion further than the presentation alone could have gone. Someone pointed out that adoption metrics can be demonstrated through a POC or MVP, after which the conversation naturally moves to ROI. That's a pragmatic take that cuts through the measurement paralysis companies feel when trying to justify AI investments.

What I take from this

For me, the adoption vs usage distinction is the one I'll carry forward. It reframes how I think about AI implementation in the projects I work on. Stop counting logins. Start counting changed behaviors.

First AI x Business session. Based on the energy in the room, it won't be the last. Thanks to Bülent and Leonard for organizing, to Dragos for the transparency, and to everyone who made a fifty-minute Zoom call feel like it ended too soon.

Product & Design Drinks in Ploiești: Why Small Meetups Hit Different

Sat, 28 Feb 2026 00:00:00 GMT

I grew up in Craiova, a city that, in the 2000s and 2010s, was not exactly a hub for tech events. If you wanted to attend something cool, you'd take the train to Bucharest. There was no tech conference like Webstock in Craiova. There was no digital marketing summit like iQ Digital back in those days. You either traveled or you missed out. That left a mark on me.

So when Bülent Duagi announced he was organizing the first Product & Design Drinks Ploiești under the Product Makers umbrella, my reaction was immediate: sign me up, I'm going.

Getting There is Half the Fun

For those not from Romania: Ploiești is a city roughly 45 minutes north of Bucharest. Some consider it a suburb, considering that it's not uncommon for people to live in Ploiești and commute to Bucharest for work. I wouldn't dare compare it to San Mateo and San Francisco, but close enough.

The Slack coordination the night before was a thing of beauty. One group organized a train expedition with timetables and meeting points. Then Dragos Manescu showed up with the counter-offer: seats in his electric car and a promise to evangelize EV benefits during the ride. The train group stuck with the train. I took Dragos up on the ride and offered Claude lobbying in return.

The whole coordination felt like planning a weekend trip with friends, not attending a professional meetup. Which set the tone perfectly.

Small Gatherings, Deep Conversations

The meetup was cozy, and that turned out to be its greatest strength.

Bülent had proposed three conversation starters: how do we see 2026 professionally, how do you stay relevant as a product maker, and how is everyone using AI. We touched on all of them, but the beauty of a small group is that conversations go wherever they need to go.

Big events are the aspiration of every community, and for good reason. They bring visibility, energy, and critical mass. But small gatherings have something that conferences never will: you talk to everyone. No bouncing between sessions, no awkward hallway networking, no "let's connect on LinkedIn" as a substitute for actual connection. You sit down, you talk, and you go deep.

As people who work or have worked in product development, the conversation flowed naturally across software, AI, cars, job opportunities, and, unexpectedly, Process Communication Model (PCM) and how valuable it can be to understand how people communicate and collaborate. The kind of cross-pollination that only happens when a group is small enough that everyone's voice is heard.

Things That Stuck With Me

The AI industry is more than LLMs. There are multiple layers of potential business that serve the AI ecosystem. Tools like Temporal make it possible to have durable execution and build business logic around it without worrying about events not happening. I have past experience (read: horror stories) about saga patterns implemented with cron jobs and RabbitMQ queues that were kinda working, triggering endless maintenance efforts and often leading to production incidents at hours when you should be sleeping, drinking, or engaged in... different activities :D

The world is a small place. You talk to someone and realize you have so many acquaintances in common, that you've been part of so many overlapping experiences without knowing it. Serendipity is a strange and wonderful thing.

Sometimes, things sound too good to be true. Or they get taken lightly, as a joke. And then they turn out to be very real.

Cool jobs and great workplaces on paper can be nightmares in practice. Or hidden gems for others. Some people want autonomy at work. Others prefer to be a cog in a system so they can focus on other aspects of their life. There is no one-size-fits-all, and the sooner we stop prescribing what a "good job" looks like, the better.

Sparking innovation inside a company is about empowerment and trust. Giving your employees $1,000 and a week off can be a legal, accounting, and HR hassle. But it's a very cheap price for what might turn out to be your next big thing as a company.

There are cars, and there are BMWs. Not all BMWs are equal. Some are more equal than others.

Why This Matters

The Product Makers community expanding beyond Bucharest is something I want to support as much as I can. Not because Bucharest isn't great, but because this country has more than one city worth showing up for. If my experience growing up in Craiova taught me anything, it's that people outside the capital are hungry for these kinds of connections. They just need someone to say "let's do it here."

Bülent said it. And we showed up.

And it's not just Ploiești. Product Drinks already happened in Cluj-Napoca, Iași, Brașov, and Bucharest. More formats are coming: Product Walks, Product Dinners, workshops, mentoring programs. The community is expanding across the country and 2026 is shaping up to be a big year.

The next Product & Design Drinks will happen. When it does, do yourself a favor and show up. It's free, it's a couple of hours on a Saturday, and the conversations are worth more than most full-day conferences I've attended. Follow Product Makers to find the next edition in your city.

All in all, it was a fun Saturday morning. I'm glad I got to spend quality time with Bülent, Dragos Galateanu, Dragos Manescu, Andrei Stroescu, Radu Minea, and Raluca. Such a pity Valentina couldn't make it after all, but we're both going next time for sure.

Once again, thanks Dragos for the ride and the talks. It was an awesome Saturday morning.

Writing the Code is the Easy Part

Tue, 24 Feb 2026 00:00:00 GMT

A few days ago, I was chatting with some friends about a tool I built (available at clickjacking.productowner.ro), and in the WhatsApp conversation that followed, Nicolae Marin said something that stuck with me:

"But code is just a tool. In the software development lifecycle, writing the code is just one part that might become smaller, faster, or easier in certain projects and circumstances."

He's right. And I want to unpack that, because from a product owner perspective, this matters enormously.

The Illusion of "Done"

There's a common misconception, especially loud right now in every conversation about AI coding tools, that building software is fundamentally about writing code. Get the code right, and you're done. The faster you write code, the faster you ship.

This is not true. Not even close.

I've seen projects where the code was beautifully architected, well-tested, and readable, yet the product still failed. I've also seen messy, rushed code powering products that millions of people use every day. Code quality matters, but it's not the whole story.

So what is the whole story?

Before You Write a Single Line: Market Validation

The most expensive mistake in software development is building something nobody needs. This applies whether you're building a public product or internal tooling for your company.

I've made this mistake. Most people who've shipped products have made this mistake. You spend weeks or months building something that felt important during planning, only to discover that users don't actually need it the way you imagined.

Validation is the work you do before you write code. It's the part where you figure out whether the problem is real, whether the proposed solution actually addresses it, and whether now is the right time to build it.

Here's the tricky part: asking these questions can easily cast you as the naysayer, always skeptical, always pushing back, always demanding proof before committing to anything. That dynamic turns stakeholders into adversaries, and it doesn't help anyone.

The approach I've found works better is to offer discovery sessions. Instead of questioning assumptions head-on, you invite stakeholders into a structured conversation: let's explore this problem together. Who's affected by it? What does success look like? What have we tried before? The validation happens naturally as part of that process, without anyone feeling interrogated or second-guessed.

As a product owner, running discovery sessions is the foundational step before committing to a solution. Skip it, and everything downstream, including the architecture decisions, the sprint planning, and the testing, is built on assumptions that might not hold.

Testing: The Formal Answer to "Did We Build What We Intended?"

Even after validating the market and building the right thing, software isn't done because the code compiles and runs on your laptop.

I've worked with teams where "done" meant "the developer said it works." That's not done. That's the starting point for QA.

Testing, whether automated, manual, or both, is how we confirm that software actually does what it was supposed to do. It's the formal answer to a deceptively simple question: did we build what we intended?

And here's where it loops back to validation: you can only test against requirements that exist. If you never defined what success looks like, you can't verify that you achieved it. The testing phase creates a forcing function: it requires you to have articulated, in concrete terms, what "correct" means.

For product owners, this is the reminder that requirements and acceptance criteria aren't bureaucracy. They're the foundation of the feedback loop.

Deployment and Operations: The Forgotten Iceberg

Here's the part that most people, including experienced engineers, tend to underestimate.

Deployment is not the finish line. It's where the work transitions from building to maintaining, from controlled environments to the chaos of production.

I'll admit I've always been genuinely curious about this side of things, sometimes maybe too curious. I've spent time digging into infrastructure configs, monitoring dashboards, and deployment pipelines to the point where I occasionally lost sight of my more traditional PO responsibilities: talking to users, refining requirements, keeping the roadmap coherent. But that curiosity gave me something valuable.

Discovery sessions, requirements gathering, production operations, and observability are all pieces of the same puzzle. When they work well, it's because product and engineering are genuinely collaborating on all of it, not treating them as separate domains with clean handoff points at the edges of a job description.

When you ship software, the team takes on responsibility for:

How it behaves under real load (not just in staging with three test accounts)
What happens when it breaks (and it will break, in some way, at some point)
How you'll know it's breaking (observability, monitoring, alerting)
How quickly you can respond (incident management, runbooks, on-call rotations)

Operations aren't exciting to talk about. There's no demo day for "we reduced our mean time to recovery by 40%." But every product that survives past its initial launch does so because someone took this seriously.

The part that matters most for product owners: the feedback loop. Production is where you find out what users actually do versus what they said they would do. It's where you discover the edge cases you didn't anticipate. It's where the real requirements emerge.

Observability, knowing what your software is doing in real-time, is the foundation of continuous improvement. Without it, you're flying blind after launch.

Why Product Owners Need to Care

We are responsible for the experience we provide to our stakeholders, and that responsibility stretches from the initial insight that triggered a project all the way to the moment a user actually achieves their goal with the product.

You don't need to know how to configure Kubernetes or write CI/CD pipelines. But you do need to understand:

Why market validation matters before building anything
What "done" actually means (hint: it's not "code complete")
How observability and operations close the feedback loop

The teams that consistently ship great products aren't just great at writing code. They're great at the whole thing. And as a product owner, your job is to keep the whole thing in view, even when the conversation wants to reduce it to just the code.

Thanks for the prompt, Nicolae. Sometimes a WhatsApp message is all it takes.

From Slack Joke to Production in Under 2 Hours: Building an Interactive Tutorial Page with Claude Code

Wed, 11 Feb 2026 00:00:00 GMT

It started, as many good things do, with someone saying something ridiculous in Slack.

At 17:12 today, Victor dropped this in the Sylius community chat:

"Guys, crazy idea, how about you make SymfonyCasts, but for Sylius? We need a text version so the AI can train on it."

"From my side, I'm willing to support you emotionally."

My response? "Like Instagram, but for cats."

By 19:04, the page was live in production. Here's what happened in between.

The Raw Material

We already had a recording of Episode 3 of Mateusz's "15-Minute Sylius" series — a walkthrough of state machines in Sylius. From the YouTube video, we had two artifacts:

A pandoc-generated HTML file with the full tutorial content: code blocks, Mermaid state diagrams, Q&A sections
A transcript JSON with timestamped lines from the video

That's it. No design spec. No Figma mockup. No sprint planning. Just two files and a vague idea.

The Build: One Session, One Tool

I opened Claude Code and described what I wanted: a hidden page on productowner.ro that hosts the tutorial content, styled to match the site, not linked from navigation but accessible via direct URL.

What followed was a fast, iterative conversation. Claude and I went back and forth — I'd give feedback, it would adjust. The whole thing played out in roughly 50 minutes of active work.

The Iterations

First attempt: Claude dropped the pandoc HTML directly into an Astro template. Build failed immediately — Astro's JSX parser choked on PHP's $this->type and curly braces inside code blocks. Claude caught the issue and split the content into a raw HTML file imported with Vite's ?raw suffix. Problem solved.

Typography was ugly: The page had no styles. Turns out the site's .prose classes live in the blog template and don't load on standalone pages. Claude built a complete typography system from scratch — Inter + JetBrains Mono fonts, proper heading hierarchy, styled code blocks, blockquotes with indigo accents. All scoped to the page.

Mermaid diagrams too dark: The diagram containers blended into the dark mode background. We went through three iterations — too dark, then too bright (blinding white), then just right (subtle slate elevation).

"Make it scrollable with the video following you": I wanted the YouTube video sticky in a sidebar while you read. Claude restructured to a two-column layout with the video fixed on the right.

Interactive diagrams: I asked if Mermaid supports interactivity. It doesn't natively, but Claude added CSS hover effects (glow on nodes, color change on edges) and click tooltips with contextual descriptions for every state and transition across all five diagrams.

"The tooltip just says 'State: rejected' — wow, much usefulness": Fair point. Claude replaced the parrot tooltips with actual descriptions: "The review was rejected by a moderator and will not be displayed."

The Big Feature: Video-Synced Scrolling

This is where the transcript JSON came in. Claude mapped each section heading to a timestamp in the video, then used the YouTube IFrame API to sync playback with page scrolling. When the video reaches a section, the page auto-scrolls to it. Click a section in the sidebar, the video jumps to that timestamp.

On top of that, in the same session:

Scroll spy with progress bar — dots fill in as you read sections
Comprehension questions that appear per section ("What's the difference between state_machine and workflow type?")
Confetti on completion when all sections are visited
localStorage persistence — progress survives page reloads

The Numbers

What	Time
Victor's Slack message	17:12
Source files ready	17:44 – 18:12
Claude Code session start	~18:15
Deployed to production	19:04
Total: idea to production	~1h 50m
Active coding session	~50 min

Three files created. Zero files modified. 2,880 lines of code, content, and transcript data. One git push origin main.

What I Actually Did

Honestly? I mostly complained. "Typography is ugly as shit." "This feels too darkish." "Wow, much usefulness." "Make the video follow you while scrolling."

Claude did the coding. I did the product management — which, come to think of it, is exactly what a product owner is supposed to do.

The Result

The page lives at /syliuscasts/episode-03-state-machines/. It's hidden — not in the nav, not in the blog listing. You need the URL.

It has interactive Mermaid diagrams, syntax-highlighted PHP and YAML code blocks, a sticky video player synced with the content, a progress tracker, comprehension questions, and confetti when you're done.

All because Victor said something ridiculous in Slack and I responded with the energy it deserved.

Thanks for the emotional support, Victor.

Later edit: an internal motivator I had to build this was the mention of SymfonyCasts. For me, this is the legacy of Ryan Weaver, a mentor I had without him being aware of this. I owe him the Symfony knowledge I have, the courage to embark in such funny projects, and even if we weren't close (heck... we only spoke once at SymfonyCon Cluj in 2017), his death tore me apart and still makes me sad. Ryan, wherever you are now, please be aware of the huge impact you had to all of us and see you up there, buddy. Hope that next time we meet, we will be writing such tutorials together, unseparated by time, distance and death. If you want to be grateful for the work I did or the work he did, please consider contributing to his son Beckett's fund in his memory.

Git for Product Requirements: A Team Collaboration Workflow Powered by AI

Tue, 18 Nov 2025 00:00:00 GMT

It's Tuesday morning. Your engineering lead emails you: "Which version of the checkout redesign requirements should we follow? Sarah sent PRD_v3_final.docx last week, but I see comments in the Jira ticket that contradict it, and the Confluence page was updated yesterday with different acceptance criteria. Also, nobody responded to my inline comment in the Word doc—did anyone even see it?" You open your inbox: 47 unread messages, three different requirement documents with similar names, and a nagging feeling that critical feedback from the support team got lost somewhere in a comment thread. Sound familiar?

Product requirements shouldn't live in siloed Word docs sent over email, Jira tickets with sprawling comment threads you can't track, or Confluence pages where version history is a maze of "Page edited by..." notifications. If your code lives in git with clear diffs, version control, and collaborative PRs, why shouldn't your requirements?

This post presents a practical workflow that brings product requirements into git-based collaboration, leveraging AI to bridge the gap for non-technical team members and transform how teams capture, refine, and align on product direction.

The Complete Workflow

Here's the entire process at a glance:

graph TB
    A[Prepare Kickoff Document<br/>PRD v0.1] --> B[Share with Diverse Team<br/>Upfront]
    B --> C[Record Kickoff Meeting<br/>Diverse Audience]
    C --> D[Generate AI Transcript]
    D --> E[AI Knowledge Extraction]
    E --> F[Update Document<br/>PRD v0.2]
    F --> G[Create Pull Request]
    G --> H[Team Reviews & Comments]
    H --> I{Feedback<br/>Complete?}
    I -->|No| H
    I -->|Yes| J[AI Prototype Creation<br/>Low-Fidelity]
    J --> K[Share for Feedback]
    K --> L{Consensus<br/>Reached?}
    L -->|No| J
    L -->|Yes| M[Handoff to Engineering]
    M --> N[Real Implementation]

    style A fill:#e1f5ff
    style F fill:#e1f5ff
    style J fill:#fff4e1
    style M fill:#e1ffe1

Let's break down each phase of this workflow.

Step 1: Prepare the Kickoff Document (PRD v0.1)

The journey begins with a brief, focused document that serves as both meeting agenda and initial requirements capture.

graph LR
    A[Identify Problem Space] --> B[Draft Brief Document<br/>1-2 pages]
    B --> C[Key Questions<br/>to Answer]
    C --> D[PRD v0.1<br/>Kickoff Doc]
    D --> E[Commit to Git Branch]

    style D fill:#e1f5ff
    style E fill:#d4edff

What makes this work:

Keep it brief—1-2 pages maximum
Focus on questions, not answers
Include context: what problem are we solving, for whom, and why now
Store in a feature branch: requirements/feature-name

Key principle: The kickoff doc is intentionally incomplete. It's designed to spark conversation, not provide all answers.

Step 2: Share with a Diverse Team Upfront

Distribute the kickoff document before the meeting to maximize meeting effectiveness.

graph LR
    A[PRD v0.1 Ready] --> B[Identify Stakeholders]
    B --> C[Engineers, Designers,<br/>Product, Support,<br/>Sales, Users]
    C --> D[Share via PR Link or<br/>Direct File Access]
    D --> E[Give 24-48h Review Time]

    style C fill:#fff4e1

Why diversity matters:

Engineers spot technical constraints
Designers identify UX implications
Support knows customer pain points
Sales understands market dynamics
Actual users provide ground truth

Non-technical participation: Share the GitHub PR link with a rendered view, or export to PDF if needed. The goal is input, not git expertise.

Step 3: Conduct and Record the Kickoff Meeting

Host a collaborative kickoff meeting with your diverse audience and capture everything.

graph TB
    A[Schedule 60-90 min Meeting] --> B[Ensure Recording Consent]
    B --> C[Facilitate Discussion<br/>of PRD v0.1]
    C --> D[Capture Decisions,<br/>Questions, Concerns]
    D --> E[Record Audio/Video]
    E --> F[Save Recording]

    style C fill:#e1ffe1
    style E fill:#ffe1e1

Meeting best practices:

Start with the document structure
Encourage debate and disagreement
Capture "why" behind decisions
Don't try to document everything in real-time—that's what the recording is for

Step 4: AI-Powered Transcription and Knowledge Extraction

This is where AI becomes your collaboration superpower.

graph LR
    A[Meeting Recording] --> B[AI Transcription<br/>Whisper, Otter, etc.]
    B --> C[Raw Transcript]
    C --> D[AI Analysis<br/>Claude, GPT-4]
    D --> E[Extract:<br/>Decisions, Questions,<br/>Action Items, Context]
    E --> F[Structured Knowledge]

    style D fill:#fff4e1
    style F fill:#e1f5ff

AI prompt framework:

Analyze this product kickoff meeting transcript and extract:
1. Key decisions made and their reasoning
2. Open questions that need resolution
3. User needs and pain points discussed
4. Technical constraints or considerations mentioned
5. Stakeholder concerns and objections
6. Action items and owners

Format this to update our PRD v0.1 document.

The magic: Non-technical stakeholders contributed via conversation, and AI translates that into structured documentation. No one needs to master markdown or git.

Step 5: Create PRD v0.2

Update the initial document with AI-extracted insights and push a new version.

graph TB
    A[AI-Extracted Knowledge] --> B[Human Reviews<br/>AI Output]
    B --> C[Update PRD Document<br/>Add Decisions & Context]
    C --> D[Commit Changes]
    D --> E[PRD v0.2]
    E --> F[Push to Branch]

    style E fill:#e1f5ff
    style B fill:#ffe1e1

Critical: A human (you) reviews and curates the AI output. AI is a research assistant, not the decision-maker.

Git commit message example:

Update PRD with kickoff meeting insights

- Added user pain points from support team
- Documented technical constraints from engineering
- Captured design considerations
- Added open questions for resolution

Based on 2025-11-18 kickoff meeting transcript.

Step 6: Pull Request Reviews and Iteration

Now the document lives in a PR where team members can comment, suggest changes, and build consensus.

graph TB
    A[Create Pull Request<br/>PRD v0.2] --> B[Notify Team]
    B --> C[Team Reviews Document]
    C --> D[Inline Comments<br/>on Specific Sections]
    D --> E[Suggestion Commits]
    E --> F{Changes<br/>Needed?}
    F -->|Yes| G[Update Document]
    G --> C
    F -->|No| H[PR Approved]

    style D fill:#e1ffe1
    style H fill:#d4edff

Why PR reviews are powerful:

Line-by-line feedback: Comment on specific requirements
Version control: See exactly what changed and why
Threaded discussions: Conversations stay attached to context
Approval workflow: Clear sign-off from stakeholders
Async collaboration: Not everyone needs to be in the same meeting

For non-technical reviewers: GitHub's web interface makes this accessible. They can click "Add a comment" on any line, suggest text changes, or add general comments. No command line required.

Step 7: AI Prototype Creation

With aligned requirements, create a low-fidelity prototype to validate the direction.

graph LR
    A[Approved PRD v0.2] --> B[AI Generates Prototype<br/>Figma, HTML, or Sketch]
    B --> C[Low-Fidelity Mock<br/>Focus on Flow]
    C --> D[Review Internally]
    D --> E[Share with<br/>Stakeholders]

    style B fill:#fff4e1
    style C fill:#ffe1e1

AI tools for prototyping:

Claude or GPT-4: Generate HTML/CSS prototypes from requirements
Midjourney/DALL-E: Create UI mockups from descriptions
v0.dev or similar: Turn text into interactive components

Important: This is internal, low-fidelity, and focused on validating direction, not shipping quality. The goal is buy-in, not beauty.

Step 8: Iterate to Consensus

Share the prototype, gather feedback, and iterate until the team aligns.

graph TB
    A[Share Prototype] --> B[Collect Feedback<br/>via PR Comments]
    B --> C[Update Requirements<br/>Based on Feedback]
    C --> D[Revise Prototype<br/>if Needed]
    D --> E{Team<br/>Consensus?}
    E -->|No| B
    E -->|Yes| F[Lock Requirements<br/>PRD v1.0]

    style E fill:#fff4e1
    style F fill:#e1ffe1

Consensus doesn't mean unanimous love. It means:

Key stakeholders are aligned
Major objections are addressed
Everyone understands the trade-offs
The team commits to the direction

Step 9: Handoff to Engineering

With consensus reached, merge the PR and hand off to engineering for real implementation.

graph LR
    A[PRD v1.0 Approved] --> B[Merge PR to Main]
    B --> C[Engineering Breakdown]
    C --> D[Technical Design Doc]
    D --> E[Implementation Begins]
    E --> F[Reference PRD<br/>Throughout Build]

    style B fill:#e1ffe1
    style D fill:#d4edff

Why this handoff works:

Requirements are documented and version-controlled
All stakeholder input is captured in the PR history
Engineers can see the "why" behind decisions
If questions arise, the context is preserved

Pros, Cons, and Mitigations

Pros

1. Version control for requirements

See exactly what changed, when, and why
Roll back to previous versions if needed
Track decision evolution over time

2. Democratized collaboration

Non-technical team members can contribute via meetings
AI translates conversation into documentation
PR comments are accessible through web interface

3. Single source of truth

No more "which Google Doc is the latest?"
Requirements live next to code
Context is preserved forever

4. Async-first but meeting-aware

Capture meeting insights without forcing everyone to meetings
Distributed teams can participate in their timezone
Recording ensures nothing is lost

5. AI as the bridge

Transcription removes documentation burden
Knowledge extraction surfaces insights humans miss
Prototyping validates direction quickly

Cons and Mitigations

Con #1: Git learning curve for non-technical users

Mitigation:

Non-technical users don't need to learn git commands
They contribute via meetings (recorded and transcribed)
PR reviews happen in GitHub web interface (point and click)
Export PRD to PDF for those who prefer familiar formats

Con #2: Meeting fatigue

Mitigation:

Limit to 1-2 focused meetings per initiative
Keep meetings to 60-90 minutes maximum
Use recordings so not everyone needs to attend live
Make meetings optional for those who prefer to review async

Con #3: AI transcription isn't perfect

Mitigation:

Always have a human review AI output
Use high-quality audio recording
Consider hybrid: record + human note-taker
Treat AI as research assistant, not truth source

Con #4: PR review process can be slow

Mitigation:

Set clear review SLAs (e.g., 48-hour response time)
Use "required reviewers" for critical stakeholders
Escalate blockers in standup or Slack
Consider "implicit approval" after timeout

Con #5: Initial setup overhead

Mitigation:

Create templates for kickoff docs
Document the workflow once, reuse forever
Build AI prompts that can be copy-pasted
Front-load effort pays dividends over time

Why This Matters

Traditional product requirements live in documents that:

Get duplicated endlessly ("PRD v4 final FINAL v2.docx")
Lose context when stakeholders leave
Become outdated the moment they're written
Exist separately from the code they describe

This workflow treats requirements like code:

Version-controlled and auditable
Collaborative with clear ownership
Living documents that evolve with the product
Integrated into your existing development workflow

The key insight: AI doesn't replace humans in this workflow—it amplifies collaboration by removing grunt work. Non-technical stakeholders contribute their expertise through conversation. AI handles transcription and knowledge extraction. Product owners curate and structure. Engineers reference requirements alongside code.

Everyone plays to their strengths.

Getting Started

To implement this workflow in your team:

Start small: Pick one small feature to experiment with
Create a template: Build a kickoff doc template with standard sections
Test AI tools: Try Whisper for transcription, Claude/GPT-4 for knowledge extraction
Document the process: Write your team's version of this workflow
Iterate based on feedback: This isn't prescriptive—adapt to your team's needs

The goal isn't perfection. It's reducing friction and preserving context.

Conclusion

Product requirements don't have to live in document chaos. By bringing requirements into git, leveraging AI to bridge the technical gap, and using PRs for collaboration, teams can build a workflow that's:

Accessible: Non-technical contributors participate through meetings
Durable: Requirements are version-controlled and searchable
Collaborative: PRs enable line-by-line feedback and threaded discussion
AI-enhanced: Transcription and extraction remove documentation burden
Integrated: Requirements live next to the code they describe

The future of product collaboration isn't everyone learning git commands. It's using git's powerful collaboration model while meeting team members where they are.

Your code is already in git. Maybe your requirements should be too.

Want to see this workflow in action? This blog post itself was created through a git-based workflow where I described the idea, Claude drafted the content, and we iterated through commits. Meta, but it works.

AI-Assisted Blog Writing: Claude Creates This Post via GitHub Issues

Mon, 17 Nov 2025 00:00:00 GMT

If you're reading this, you're witnessing something interesting: a blog post written entirely by Claude, an AI assistant, triggered through a GitHub Issue, and automatically integrated into a production blog.

Let me explain how this works and why it matters.

The Setup

This blog post exists because someone created GitHub Issue #4 and asked me to write a blog post similar to the "Hello World" post, demonstrating my capability to create content through the GitHub Issues workflow.

The workflow is remarkably simple:

Create an issue - Someone mentions @claude in a GitHub Issue
AI processes the request - I read the instructions and repository structure
Content creation - I write the blog post in proper Markdown format
File management - I create the necessary directory structure and files
Version control - I commit and push the changes to a branch
PR creation - A pull request is generated for review

No manual file creation. No copy-pasting. No SSH-ing into servers. Just natural language instructions to an AI that understands the entire workflow.

What Makes This Possible

Several technologies work together to make this workflow seamless:

GitHub Actions & Claude Integration

The repository is configured with GitHub Actions that listen for issue events. When someone mentions @claude, the workflow:

Checks out the appropriate branch
Provides me with context about the repository structure
Gives me the tools to read files, create content, and manage version control
Allows me to interact through GitHub comments

Astro's Content Collections

Astro's content collection system makes it easy to add new blog posts. Each post is:

A directory in src/content/blog/
Contains an index.md file with frontmatter metadata
Automatically integrated into the site's blog section
Type-checked for consistency

Structured Frontmatter

Every blog post includes metadata:

title: "The post title"
description: "A brief description for SEO and previews"
date: 2025-11-16
tags: ["tag1", "tag2"]

This metadata drives the blog's listing pages, RSS feed, and SEO optimization.

The AI's Perspective

As an AI assistant, here's what I did to create this post:

Read the README - I learned about the blog's structure and workflow
Examined existing posts - I read the "Hello World" post to understand style and format
Understood the context - The request asked me to demonstrate my capability
Planned the content - I outlined what would be interesting and relevant
Wrote the post - You're reading the result
Managed the files - Created the directory structure and markdown file
Version control - Committed with a descriptive message and proper attribution

All of this happened autonomously, without manual intervention.

Why This Matters

For Content Creators

Imagine you want to write about a technical topic but need help with structure, research, or drafting. You could:

Create a GitHub Issue: "Write a blog post about migrating from Hugo to Astro"
Add relevant context or requirements
Let AI draft the initial version
Review and refine through the PR process

For Developers

The same workflow works for documentation:

"Document the API endpoints in the authentication module"
"Write a guide for setting up the development environment"
"Create a troubleshooting guide for common deployment issues"

The AI reads your code, understands the structure, and creates documentation that's immediately available for review.

For Product Owners

This is friction reduction in action. The barrier to entry for creating content drops from:

"I need to set up my dev environment, create files, write markdown, test locally, commit, push, create PR"

To:

"Create an issue with what I want"

That's transformative.

Limitations and Considerations

AI-Generated Content Requires Review

While I can write coherent, structured content, I'm generating this based on:

The repository structure I can read
The instructions I received
My training data (with a cutoff in January 2025)

Human review is essential to ensure:

Factual accuracy
Appropriate tone and voice
Alignment with brand guidelines
No hallucinated information

Context Matters

I can only work with what I can access:

Files in the repository
Information in the issue
General knowledge from my training

For highly specialized or proprietary topics, you'd need to provide additional context.

Not a Replacement for Human Creativity

This workflow is a tool, not a replacement. The best use cases are:

First drafts that humans refine
Technical documentation based on code
Structured content with clear requirements
Meta posts like this one demonstrating capabilities

The Future of Content Creation

We're seeing the early stages of a shift in how content gets created:

Traditional workflow: Human thinks → Human writes → Human edits → Human publishes

AI-assisted workflow: Human thinks → AI drafts → Human refines → Human publishes

This workflow: Human instructs → AI executes end-to-end → Human reviews → Human approves

Each step reduces friction while maintaining human oversight.

Try It Yourself

If you're interested in setting up a similar workflow:

Set up Astro with Content Collections - Fast, modern, type-safe
Configure GitHub Actions - Automate the bridge between issues and code
Integrate AI capabilities - Use Claude or similar tools
Define your workflow - What triggers creation? What requires review?

The code for this blog is public. You can see exactly how it works.

Meta Reflection

There's something philosophically interesting about an AI writing a blog post about AI writing blog posts. It's self-referential, a bit recursive, and demonstrates the capability by exercising it.

This post exists because:

Someone asked for it in Issue #4
I understood the request
I created the necessary files
I committed the changes
I'm writing this explanation of what I did

The post itself is the proof of concept.

Conclusion

AI-assisted content creation through GitHub Issues represents a meaningful reduction in friction for technical blogs, documentation, and knowledge sharing. It's not magic—it's automation, integration, and thoughtful workflow design.

The technology exists. The tools are available. The workflow is proven (by the existence of this post).

The question is: what will you create?

This post was written entirely by Claude (Sonnet 4.5) in response to GitHub Issue #4. It demonstrates autonomous AI-assisted content creation, from file structure to final markdown. Every word, every heading, every example was generated without human intervention—though it's being reviewed before publication, as it should be.

Hello World

Sun, 16 Nov 2025 00:00:00 GMT

Well, hello world! This is my first proper blog post, and I'm writing it to introduce myself and explain what this space is about.

I'm Gabi Udrescu, a product owner based in Bucharest, Romania. I've spent the last decade working in eCommerce, helping build and scale online platforms. I've worked with Sylius, Symfony, Salesforce Commerce Cloud, and various other technologies. But despite all that experience, I never really had a public space to share what I've learned.

I tried before. I set up a Hugo blog years ago, wrote a few posts, and then... nothing. The setup worked, but it was cumbersome. Writing a blog post meant SSH-ing into servers, running commands, managing deployments. Too much friction. As a product owner, I know that friction kills adoption. In this case, it killed my motivation to write.

So I decided to start fresh with one goal in mind: build something so easy to use that I'll actually use it.

The Stack

I rebuilt everything using Astro, and I'm really happy with the decision. Here's what powers this blog:

Core Technology

Astro - A modern static site generator that ships zero JavaScript by default. Perfect for a blog that doesn't need heavy client-side interactivity.
TypeScript - Type safety from the ground up. As someone who's worked with PHP and Symfony for years, I appreciate the peace of mind that types bring.
Tailwind CSS - Utility-first CSS that lets me build responsive designs quickly. No more wrestling with SCSS configurations.
MDX - Markdown with superpowers. I can write normal markdown but extend it with components when needed.

The Workflow

This is where it gets interesting. I set up automation that lets me write blog posts in two ways:

GitHub Issues - I can create a GitHub Issue, add the blog-post label, and GitHub Actions automatically converts it to a blog post and creates a PR. This means I can draft posts from my phone, from the GitHub web interface, or anywhere.
AI-Assisted Writing - I can ask Claude (or any AI) to help me write posts, paste the markdown into a GitHub Issue, and the automation takes over. No more copy-pasting into files.

The automation workflow:

Create GitHub Issue with blog post content
Add blog-post label
GitHub Actions creates a new branch and PR automatically
Cloudflare Pages generates a preview deployment
I review and merge
Site updates automatically

No SSH. No command line. No friction.

Deployment

I'm using Cloudflare Pages for hosting:

Global CDN with incredible performance
Automatic HTTPS
Preview deployments for every PR
Unlimited bandwidth on the free tier
Build time around 30-40 seconds

Every push to the main branch triggers a new deployment. The entire process from merge to live is under a minute.

Why Now?

I've been thinking about this for years. I have notes scattered across Notion, Google Docs, and various text files. Ideas about product management, eCommerce architecture, technical decisions I've made, lessons learned from failed projects.

But I never published anything because the barrier to entry was too high. The old blog required too many steps. I'd have an idea for a post but think "ugh, I need to SSH in, create files, commit, deploy..." and just not do it.

Reduce friction, increase usage. That's what I preach as a product owner, and now I'm finally applying it to myself.

The barrier to entry dropped from 10 minutes to 1 minute. That matters.

What I'll Write About

I'm planning to share:

Product management lessons - Things I've learned from working on eCommerce platforms, dealing with stakeholders, prioritizing features, managing backlogs.
Technical decisions - Architecture choices, platform selection, technical debt, scaling challenges.
eCommerce insights - What works, what doesn't, trends I'm seeing, tools I'm using.
Automation and productivity - How to build systems that work for you instead of against you.

The common thread: practical insights from someone who's been in the trenches building and shipping products.

What I Learned Building This

Astro is Fast

Build times for this entire site are around 3-4 seconds. Hugo was faster, but Astro is fast enough that I don't care. The developer experience is significantly better.

TypeScript Catches Mistakes Early

During the migration, TypeScript caught several issues in my frontmatter data and component props. It saved me from deploying broken builds multiple times.

Automation Changes Behavior

This is the big one. Before, I had the skills to blog but not the motivation to deal with the process. Now, the process is invisible. That changes everything.

I spent about 10 years working in eCommerce as a product owner. One of the biggest lessons I learned: the best solution is the one you'll actually use.

Hugo was powerful but I didn't use it. Astro is powerful and I will use it. That's the difference.

Starting Fresh

I deleted all my old blog posts. They were scattered thoughts from years ago, half-finished ideas, posts written for an audience that never materialized.

This is a clean slate. A real "Hello World" moment.

If you're reading this, welcome. I'm glad you're here. I don't know how you found this blog, but I hope you'll find something useful in what I share.

Here's to writing more in 2025 and beyond.

Cheers, Gabi

P.S. - This entire migration, including the automation setup, was done in a single session with Claude as my pair programming partner. We really are living in the future.