{ "version": "https://jsonfeed.org/version/1.1", "title": "Phil Stephens - all posts", "description": "All of my posts", "home_page_url": "https://philstephens.com", "feed_url": "https://philstephens.com/feed/posts/json", "language": "en-US", "authors": [{ "name": "Phil Stephens" } ], "items": [{ "id": "https://philstephens.com/112", "title": "The risks of adopting AI-led development (my humble opinion)", "url": "https://philstephens.com/blog/the-risks-of-adopting-ai-led-development-my-humble-opinion", "content_html": "

There is a lot of pressure right now to adopt AI-led development practices, and most of it is coming from outside engineering. Boards want productivity gains. Investors want AI in the pitch deck. CEOs want to be seen leading the transition rather than catching up to it. The question that tends to get skipped in all of that is the one engineering leaders actually have to answer: if we change how our teams work, what can go wrong, and what do we do about it?<\/p>\n

I am genuinely enthusiastic about these tools. I use Claude Code and OpenAI Codex daily, and I think the productivity gains for experienced engineers are real. But I also think the disposition this transition needs (especially from the people leading it) is well-founded<\/em> enthusiasm rather than uncritical<\/em> enthusiasm. There are three risks I keep coming back to, in roughly this order of importance.<\/p>\n

Erosion of review discipline<\/h2>\n

The biggest risk is not AI writing bad code. AI writes pretty good code, most of the time. The risk is humans stopping reading it carefully. Output that looks plausible gets waved through. What used to be a meaningful review becomes a rubber stamp. Six months in, you have a codebase where nobody is entirely sure who understood what before it shipped.<\/p>\n

Part of what makes this risk so pernicious is that it is partly structural, not just a matter of individual laziness. AI coding agents dramatically increase the throughput of code being created. They do not, on their own, increase the speed at which code gets reviewed. Review is still a human activity, constrained by how much context a person can hold in their head and how carefully they can reason about a change. So the bottleneck shifts. Writing code stops being the slow part. Reviewing it properly<\/em> becomes the new constraint on delivery.<\/p>\n

That is not, in itself, a problem. It is arguably a healthy rebalancing. The problem is what happens next. Teams that were previously judged on how much code they shipped now find their throughput pinned at the review stage, and the pressure to loosen up starts to build. Pull requests sit open for days. A backlog of AI-generated changes accumulates. Someone, somewhere, decides that reviews need to move faster, and the obvious way to make that happen is to read less carefully. The discipline does not collapse because anyone consciously chose to abandon it; it erodes because the system is now producing more output than the old review process was designed to absorb.<\/p>\n

The mitigation, I think, is to be very explicit with the team that AI changes who writes the first draft, but not who is accountable for what ships. Standards for testing, observability, and CI become more important, not less. Review criteria should tighten rather than relax. If a reviewer cannot explain what a change does and why it is correct, it is not ready to merge, regardless of who or what drafted it. And if that genuinely slows delivery, the honest answer is that the team's actual delivery rate was always constrained by how much code it could responsibly ship, not by how much it could type. AI tools have just made that constraint visible.<\/p>\n

Most of the security and IP-leakage incidents I have seen discussed are downstream symptoms of this same discipline gap. Treat the discipline as the primary control point and a lot of the secondary concerns become easier to manage.<\/p>\n

Skill atrophy, particularly for less experienced engineers<\/h2>\n

Mid and senior engineers have the mental models to spot when AI-generated code is wrong in subtle ways. Juniors often do not yet, and handing them a tool that produces confident, articulate output can short-circuit the deliberate practice they need to build those models in the first place.<\/p>\n

This one worries me more the longer I think about it. The path from junior to senior runs through a lot of staring at broken code, reading documentation, and figuring out why the obvious solution is wrong. If that path is replaced by prompting until something works, we risk producing a generation of engineers who are extremely productive in familiar territory and completely stuck the moment they leave it.<\/p>\n

The mitigation is pairing, structured learning expectations, and being deliberate about which work gets done with AI assistance and which gets done as foundational skill-building. Juniors will benefit enormously from these tools - but only if we protect the conditions that let them become seniors.<\/p>\n

Cargo-culting complex patterns where simpler ones would do<\/h2>\n

It is tempting, particularly when your board is asking about AI strategy, to reach for autonomous agents or elaborate multi-step workflows when a constrained chain or a well-scoped function call would deliver the same outcome more reliably, more cheaply, and more predictably.<\/p>\n

Knowing when not<\/em> to use agents is, I think, a genuine signal of engineering maturity. A boring, reliable LLM feature that customers can depend on is almost always more valuable than an impressive demo that works in the pitch and fails in production.<\/p>\n

\n

These three risks are connected, and the connection matters. AI accelerates whatever foundation already exists - good practice or bad. Teams with solid review culture, clear testing standards, and engineers who know when to reach for simple tools will ship better software, faster. Teams without those things will ship worse software, faster.<\/p>\n

That means the work of leading an AI-led development transition is at least as much about strengthening fundamentals as it is about rolling out tooling. I would even argue the tooling is the easier part. Tools can be installed in an afternoon. Changing how a team thinks about review, about junior development, and about architectural restraint takes considerably longer - and without those changes, the tools amplify exactly the problems you were hoping they would solve.<\/p>\n

Email a comment<\/a><\/p>", "summary": "

There is a lot of pressure right now to adopt AI-led development practices, and most of it is coming from outside engineering. Boards want productivity gains. Investors want AI in the pitch deck. CEOs want to be seen leading the transition rather than catching up to it. The question that tends to get skipped in all of that is the one engineering leaders actually have to answer: if we change how our teams work, what can go wrong, and what do we do about it?<\/p>\n

I am genuinely enthusiastic about these tools. I use Claude Code and OpenAI Codex daily, and I think the productivity gains for experienced engineers are real. But I also think the disposition this transition needs (especially from the people leading it) is well-founded<\/em> enthusiasm rather than uncritical<\/em> enthusiasm. There are three risks I keep coming back to, in roughly this order of importance.<\/p>\n

Erosion of review discipline<\/h2>\n

The biggest risk is not AI writing bad code. AI writes pretty good code, most of the time. The risk is humans stopping reading it carefully. Output that looks plausible gets waved through. What used to be a meaningful review becomes a rubber stamp. Six months in, you have a codebase where nobody is entirely sure who understood what before it shipped.<\/p>\n

Part of what makes this risk so pernicious is that it is partly structural, not just a matter of individual laziness. AI coding agents dramatically increase the throughput of code being created. They do not, on their own, increase the speed at which code gets reviewed. Review is still a human activity, constrained by how much context a person can hold in their head and how carefully they can reason about a change. So the bottleneck shifts. Writing code stops being the slow part. Reviewing it properly<\/em> becomes the new constraint on delivery.<\/p>\n

That is not, in itself, a problem. It is arguably a healthy rebalancing. The problem is what happens next. Teams that were previously judged on how much code they shipped now find their throughput pinned at the review stage, and the pressure to loosen up starts to build. Pull requests sit open for days. A backlog of AI-generated changes accumulates. Someone, somewhere, decides that reviews need to move faster, and the obvious way to make that happen is to read less carefully. The discipline does not collapse because anyone consciously chose to abandon it; it erodes because the system is now producing more output than the old review process was designed to absorb.<\/p>\n

The mitigation, I think, is to be very explicit with the team that AI changes who writes the first draft, but not who is accountable for what ships. Standards for testing, observability, and CI become more important, not less. Review criteria should tighten rather than relax. If a reviewer cannot explain what a change does and why it is correct, it is not ready to merge, regardless of who or what drafted it. And if that genuinely slows delivery, the honest answer is that the team's actual delivery rate was always constrained by how much code it could responsibly ship, not by how much it could type. AI tools have just made that constraint visible.<\/p>\n

Most of the security and IP-leakage incidents I have seen discussed are downstream symptoms of this same discipline gap. Treat the discipline as the primary control point and a lot of the secondary concerns become easier to manage.<\/p>\n

Skill atrophy, particularly for less experienced engineers<\/h2>\n

Mid and senior engineers have the mental models to spot when AI-generated code is wrong in subtle ways. Juniors often do not yet, and handing them a tool that produces confident, articulate output can short-circuit the deliberate practice they need to build those models in the first place.<\/p>\n

This one worries me more the longer I think about it. The path from junior to senior runs through a lot of staring at broken code, reading documentation, and figuring out why the obvious solution is wrong. If that path is replaced by prompting until something works, we risk producing a generation of engineers who are extremely productive in familiar territory and completely stuck the moment they leave it.<\/p>\n

The mitigation is pairing, structured learning expectations, and being deliberate about which work gets done with AI assistance and which gets done as foundational skill-building. Juniors will benefit enormously from these tools - but only if we protect the conditions that let them become seniors.<\/p>\n

Cargo-culting complex patterns where simpler ones would do<\/h2>\n

It is tempting, particularly when your board is asking about AI strategy, to reach for autonomous agents or elaborate multi-step workflows when a constrained chain or a well-scoped function call would deliver the same outcome more reliably, more cheaply, and more predictably.<\/p>\n

Knowing when not<\/em> to use agents is, I think, a genuine signal of engineering maturity. A boring, reliable LLM feature that customers can depend on is almost always more valuable than an impressive demo that works in the pitch and fails in production.<\/p>\n

\n

These three risks are connected, and the connection matters. AI accelerates whatever foundation already exists - good practice or bad. Teams with solid review culture, clear testing standards, and engineers who know when to reach for simple tools will ship better software, faster. Teams without those things will ship worse software, faster.<\/p>\n

That means the work of leading an AI-led development transition is at least as much about strengthening fundamentals as it is about rolling out tooling. I would even argue the tooling is the easier part. Tools can be installed in an afternoon. Changing how a team thinks about review, about junior development, and about architectural restraint takes considerably longer - and without those changes, the tools amplify exactly the problems you were hoping they would solve.<\/p>\n

Email a comment<\/a><\/p>", "date_published": "2026-04-21T00:00:00+10:00", "date_modified": "2026-04-21T00:00:00+10:00", "authors": [{ "name": "Phil Stephens" }], "tags": [ ] }, { "id": "https://philstephens.com/111", "title": "How I Actually Use AI Coding Tools", "url": "https://philstephens.com/blog/how-i-actually-use-ai-coding-tools", "content_html": "

As I apply for new roles, I keep getting asked the same question: how do I use AI coding tools? It comes up in almost every conversation now - and each time, I find myself explaining the same framework. So I figured I'd document it.<\/p>\n

This is a snapshot of how I use these tools today. I fully expect it to change as the technology advances - it already looks different from six months ago. But right now, my usage has settled into four distinct modes, and I think the distinction matters more than most people realise. Prompting an AI to build you a throwaway script is a fundamentally different activity from using it to add features to a codebase you know inside out, and treating them the same is where people get into trouble.<\/p>\n

Some context: I've been on a career break since mid-2025, so most of my usage has been on personal projects rather than production systems. That's meant less pressure, more room to experiment, and a front-row seat to watch these tools go from promising-but-clunky to genuinely good. I use Claude Code and OpenAI's Codex as my primary tools, paying for both but not on the expensive Pro or Max tiers. I don't have the budget to burn through tokens the way some of the "vibe coding" crowd seem to. In practice, I bounce between the two - partly because they have different strengths, but honestly, often just to work around rate limits.<\/p>\n

Mode 1: Accelerating What I Already Know<\/h2>\n

When I'm working in PHP and Laravel - my bread and butter - I'm not asking the AI to figure out how to build something. I already know how. The AI is there to make the mechanical parts faster.<\/p>\n

I've been dropping back into pre-existing codebases with a coding agent to backfill tests, tighten up code against best practices, refactor, add documentation, and build new features. My personal blog runs on a custom CMS, and I've also rebuilt a micro-blog system from an earlier project. These are codebases I understand deeply, and that understanding is what makes the AI useful rather than dangerous.<\/p>\n

Over time, I've built up a set of custom commands and skills to streamline this work. For example, I have a \/readme<\/code> command that appraises the codebase and updates the README with any changes. These aren't anything fancy - skills are just prompts - but I've built them iteratively as patterns emerge. If I find myself repeating a prompt, I convert it into a skill, then refine it over time as I get a better feel for what the models respond well to. It's the same instinct as any developer abstracting a repeated pattern. The tooling just happens to be natural language.<\/p>\n

In this mode, my existing expertise acts as a quality filter. I can spot when the AI suggests something that's technically correct but idiomatically wrong, or when it's taken a shortcut that'll cause problems later. This is where I think experienced developers get the most leverage - not by handing over control, but by accelerating the parts of coding that were already mechanical.<\/p>\n

Mode 2: Learning With a Safety Net<\/h2>\n

I've been building a SwiftUI app for managing household chores - complete with iCloud sync and collaboration. It's a personal project, but I've approached it with the rigour of a production app, and I'll be publishing it to the App Store shortly.<\/p>\n

SwiftUI is not a language I have deep muscle memory in, and that changes the dynamic completely. The AI handles the syntax and platform-specific idioms I haven't internalised yet, while I focus on architecture and logic - things that transfer across languages and frameworks.<\/p>\n

But I'm reading every line. I'm asking why it chose one pattern over another. I'm looking up constructs I don't recognise. The AI is essentially a patient tutor who also writes working code, and the code itself becomes a learning artifact. This is genuinely faster than tutorials and documentation alone, because I'm learning in the context of the thing I actually want to build, not a toy example.<\/p>\n

The tradeoff is speed. This mode is slower than Mode 1 because I'm stopping to understand, not just shipping. But the goal isn't speed - it's competence. The spec tends to be very clear and focused, which helps keep the AI on track and gives me a solid basis to evaluate what it produces.<\/p>\n

Mode 3: Disposable Tools<\/h2>\n

Sometimes I need a tool and I genuinely don't care about the code.<\/p>\n

I built a CLI tool in Swift to export my Photos library into a specific folder structure - different from what Apple's built-in export gives you. I wrote a Python script to upload my entire Instagram history to my micro-blog. In both cases, I gave the AI maximum freedom. It picked the approach, the libraries, whatever it wanted. I ran the result, checked the output, and moved on.<\/p>\n

This is the mode where AI coding tools deliver the most obvious, immediate value. Things that would have taken half an hour of documentation-reading and boilerplate now take a few minutes of conversation. The ROI is hard to argue with.<\/p>\n

It's also the least interesting mode to talk about, because it doesn't require much skill or judgment. The AI handles it, it works (or you tell it what's wrong and it fixes it), and you get on with your day.<\/p>\n

Mode 4: Prototypes<\/h2>\n

This sits somewhere between Modes 2 and 3. I care about the code more than a throwaway tool, but I'm less sure about the approach. These are experiments that might graduate into Mode 1 projects if they prove out.<\/p>\n

I built a RAG-based chatbot using Confluence documents as a proof-of-concept for my wife to use at work. I've also built a simple SwiftUI app as a mobile companion for my micro-blog platform. Neither of these is production-ready, but they're more than disposable - they're me testing whether an idea has legs before committing to building it properly.<\/p>\n

What I've Learned Along the Way<\/h2>\n

Iterative beats one-shot, every time.<\/strong> With the exception of genuinely disposable tools, I don't try to generate entire features in a single prompt. Even with a comprehensive spec and the most capable model available, one-shotting tends to produce code that looks<\/em> right but isn't quite. The app appears to work, but when you dig into the detail, specified functionality is missing or subtly wrong. The model doesn't hallucinate - it just quietly doesn't do the thing. That's a harder failure mode to catch than an obvious error, and it's why I prefer building iteratively, the same way I would by hand. Catch issues early, maintain quality, and keep a handle on token usage in the process.<\/p>\n

A fresh set of eyes matters - even when those eyes are artificial.<\/strong> Beyond balancing token usage, I switch between Claude Code and Codex when one model gets stuck on a problem. A concrete example: my SwiftUI chores app worked perfectly in the development environment, but when I pushed to TestFlight - which hits the production database - nothing synced. Codex went round in circles trying different fixes. I switched to Claude, which spotted immediately that the development environment was hardcoded. A fresh context, without the history of failed attempts, made the difference.<\/p>\n

Different tools have different strengths.<\/strong> For the kind of work I do, Codex tends to be better at big-picture coding - scaffolding, broad strokes, getting a feature stood up. Claude is stronger in the details - spotting subtle bugs, understanding nuanced requirements, getting the specifics right. Having both available means I'm rarely completely stuck.<\/p>\n

Model choice matters more than people think.<\/strong> Rather than defaulting to the most capable model for every prompt, I'll use a lighter model for simpler tasks - refactoring, renaming, documentation, generating commit messages. It saves tokens, it's faster, and for mechanical tasks the output is just as good. Treating model selection as a conscious decision rather than always reaching for the top shelf is one of the easiest ways to get more out of these tools on a budget.<\/p>\n

Your expertise is the multiplier.<\/strong> This is the thing I keep coming back to. The better you already understand what you're building, the more value you extract from these tools. They're an amplifier. In Mode 1, my deep knowledge of Laravel means I can move fast and catch mistakes. In Mode 2, my general software engineering experience lets me evaluate SwiftUI code I couldn't have written from scratch. Even in Mode 3, knowing what the output should<\/em> look like means I can validate it quickly. The tools are powerful, but the judgment is yours.<\/p>\n

\n

There are thousands of blog posts about AI coding tools, written by people with different budgets, different experience levels, and different appetites for letting the AI drive. This is just how I've found myself working - four modes, each with its own balance of control and delegation. Your mileage will vary. But if there's one thing I'd suggest, it's being deliberate about which mode you're in. The tool doesn't change. How you use it does.<\/p>\n

Email a comment<\/a><\/p>", "summary": "

As I apply for new roles, I keep getting asked the same question: how do I use AI coding tools? It comes up in almost every conversation now - and each time, I find myself explaining the same framework. So I figured I'd document it.<\/p>\n

This is a snapshot of how I use these tools today. I fully expect it to change as the technology advances - it already looks different from six months ago. But right now, my usage has settled into four distinct modes, and I think the distinction matters more than most people realise. Prompting an AI to build you a throwaway script is a fundamentally different activity from using it to add features to a codebase you know inside out, and treating them the same is where people get into trouble.<\/p>\n

Some context: I've been on a career break since mid-2025, so most of my usage has been on personal projects rather than production systems. That's meant less pressure, more room to experiment, and a front-row seat to watch these tools go from promising-but-clunky to genuinely good. I use Claude Code and OpenAI's Codex as my primary tools, paying for both but not on the expensive Pro or Max tiers. I don't have the budget to burn through tokens the way some of the "vibe coding" crowd seem to. In practice, I bounce between the two - partly because they have different strengths, but honestly, often just to work around rate limits.<\/p>\n

Mode 1: Accelerating What I Already Know<\/h2>\n

When I'm working in PHP and Laravel - my bread and butter - I'm not asking the AI to figure out how to build something. I already know how. The AI is there to make the mechanical parts faster.<\/p>\n

I've been dropping back into pre-existing codebases with a coding agent to backfill tests, tighten up code against best practices, refactor, add documentation, and build new features. My personal blog runs on a custom CMS, and I've also rebuilt a micro-blog system from an earlier project. These are codebases I understand deeply, and that understanding is what makes the AI useful rather than dangerous.<\/p>\n

Over time, I've built up a set of custom commands and skills to streamline this work. For example, I have a \/readme<\/code> command that appraises the codebase and updates the README with any changes. These aren't anything fancy - skills are just prompts - but I've built them iteratively as patterns emerge. If I find myself repeating a prompt, I convert it into a skill, then refine it over time as I get a better feel for what the models respond well to. It's the same instinct as any developer abstracting a repeated pattern. The tooling just happens to be natural language.<\/p>\n

In this mode, my existing expertise acts as a quality filter. I can spot when the AI suggests something that's technically correct but idiomatically wrong, or when it's taken a shortcut that'll cause problems later. This is where I think experienced developers get the most leverage - not by handing over control, but by accelerating the parts of coding that were already mechanical.<\/p>\n

Mode 2: Learning With a Safety Net<\/h2>\n

I've been building a SwiftUI app for managing household chores - complete with iCloud sync and collaboration. It's a personal project, but I've approached it with the rigour of a production app, and I'll be publishing it to the App Store shortly.<\/p>\n

SwiftUI is not a language I have deep muscle memory in, and that changes the dynamic completely. The AI handles the syntax and platform-specific idioms I haven't internalised yet, while I focus on architecture and logic - things that transfer across languages and frameworks.<\/p>\n

But I'm reading every line. I'm asking why it chose one pattern over another. I'm looking up constructs I don't recognise. The AI is essentially a patient tutor who also writes working code, and the code itself becomes a learning artifact. This is genuinely faster than tutorials and documentation alone, because I'm learning in the context of the thing I actually want to build, not a toy example.<\/p>\n

The tradeoff is speed. This mode is slower than Mode 1 because I'm stopping to understand, not just shipping. But the goal isn't speed - it's competence. The spec tends to be very clear and focused, which helps keep the AI on track and gives me a solid basis to evaluate what it produces.<\/p>\n

Mode 3: Disposable Tools<\/h2>\n

Sometimes I need a tool and I genuinely don't care about the code.<\/p>\n

I built a CLI tool in Swift to export my Photos library into a specific folder structure - different from what Apple's built-in export gives you. I wrote a Python script to upload my entire Instagram history to my micro-blog. In both cases, I gave the AI maximum freedom. It picked the approach, the libraries, whatever it wanted. I ran the result, checked the output, and moved on.<\/p>\n

This is the mode where AI coding tools deliver the most obvious, immediate value. Things that would have taken half an hour of documentation-reading and boilerplate now take a few minutes of conversation. The ROI is hard to argue with.<\/p>\n

It's also the least interesting mode to talk about, because it doesn't require much skill or judgment. The AI handles it, it works (or you tell it what's wrong and it fixes it), and you get on with your day.<\/p>\n

Mode 4: Prototypes<\/h2>\n

This sits somewhere between Modes 2 and 3. I care about the code more than a throwaway tool, but I'm less sure about the approach. These are experiments that might graduate into Mode 1 projects if they prove out.<\/p>\n

I built a RAG-based chatbot using Confluence documents as a proof-of-concept for my wife to use at work. I've also built a simple SwiftUI app as a mobile companion for my micro-blog platform. Neither of these is production-ready, but they're more than disposable - they're me testing whether an idea has legs before committing to building it properly.<\/p>\n

What I've Learned Along the Way<\/h2>\n

Iterative beats one-shot, every time.<\/strong> With the exception of genuinely disposable tools, I don't try to generate entire features in a single prompt. Even with a comprehensive spec and the most capable model available, one-shotting tends to produce code that looks<\/em> right but isn't quite. The app appears to work, but when you dig into the detail, specified functionality is missing or subtly wrong. The model doesn't hallucinate - it just quietly doesn't do the thing. That's a harder failure mode to catch than an obvious error, and it's why I prefer building iteratively, the same way I would by hand. Catch issues early, maintain quality, and keep a handle on token usage in the process.<\/p>\n

A fresh set of eyes matters - even when those eyes are artificial.<\/strong> Beyond balancing token usage, I switch between Claude Code and Codex when one model gets stuck on a problem. A concrete example: my SwiftUI chores app worked perfectly in the development environment, but when I pushed to TestFlight - which hits the production database - nothing synced. Codex went round in circles trying different fixes. I switched to Claude, which spotted immediately that the development environment was hardcoded. A fresh context, without the history of failed attempts, made the difference.<\/p>\n

Different tools have different strengths.<\/strong> For the kind of work I do, Codex tends to be better at big-picture coding - scaffolding, broad strokes, getting a feature stood up. Claude is stronger in the details - spotting subtle bugs, understanding nuanced requirements, getting the specifics right. Having both available means I'm rarely completely stuck.<\/p>\n

Model choice matters more than people think.<\/strong> Rather than defaulting to the most capable model for every prompt, I'll use a lighter model for simpler tasks - refactoring, renaming, documentation, generating commit messages. It saves tokens, it's faster, and for mechanical tasks the output is just as good. Treating model selection as a conscious decision rather than always reaching for the top shelf is one of the easiest ways to get more out of these tools on a budget.<\/p>\n

Your expertise is the multiplier.<\/strong> This is the thing I keep coming back to. The better you already understand what you're building, the more value you extract from these tools. They're an amplifier. In Mode 1, my deep knowledge of Laravel means I can move fast and catch mistakes. In Mode 2, my general software engineering experience lets me evaluate SwiftUI code I couldn't have written from scratch. Even in Mode 3, knowing what the output should<\/em> look like means I can validate it quickly. The tools are powerful, but the judgment is yours.<\/p>\n

\n

There are thousands of blog posts about AI coding tools, written by people with different budgets, different experience levels, and different appetites for letting the AI drive. This is just how I've found myself working - four modes, each with its own balance of control and delegation. Your mileage will vary. But if there's one thing I'd suggest, it's being deliberate about which mode you're in. The tool doesn't change. How you use it does.<\/p>\n

Email a comment<\/a><\/p>", "date_published": "2026-04-01T00:00:00+10:00", "date_modified": "2026-04-01T00:00:00+10:00", "authors": [{ "name": "Phil Stephens" }], "tags": [ ] }, { "id": "https://philstephens.com/110", "title": "I Let AI Interview Me to Rewrite My Resume", "url": "https://philstephens.com/blog/i-let-ai-interview-me-to-rewrite-my-resume", "content_html": "

I've been job hunting for about two months now. If you've read my earlier posts, you'll know it hasn't been smooth. The rejections have been consistent, the feedback generic, and the pattern frustratingly clear: my experience isn't the problem - my resume is.<\/p>\n

That's a hard thing to admit when you've spent weeks refining it. But the evidence was difficult to ignore. Roles I was genuinely qualified for were filtering me out before a human ever read a word. And when I did get through to a screening call, the outcome was the same polite, non-specific rejection that tells you nothing useful.<\/p>\n

So I tried something different. I sat down with Claude<\/a> - Anthropic's AI assistant - and asked it to help me rewrite my resume. What I didn't expect was how the process would unfold.<\/p>\n

The resume I started with<\/h2>\n

My original resume was pretty good. It listed my roles, my titles, my skills. It had bullet points that described what I did at each company. It was accurate - but it was completely failing to land.<\/p>\n

The problem, I think, is that I wrote it the way most of us write resumes: as a factual record. Here's where I worked, here's what my title was, here's a sanitised summary of my responsibilities. It read like a job description, not a story. And in a market where your CV has about six seconds to make an impression - assuming it gets past the ATS at all - "accurate but unremarkable" is a death sentence.<\/p>\n

The interview<\/h2>\n

I expected Claude to take my resume, sprinkle some stronger verbs on it, and hand it back. Instead, it started asking questions. A lot of questions.<\/p>\n

Not surface-level ones either. It wanted to know what was actually broken when I joined Company X<\/em>. How bad was the codebase? What did the team look like? What specific changes did I make, and what happened as a result? It asked about team sizes, revenue figures, client numbers, reporting lines. It pushed on the gap between my job titles and what I was actually doing. It asked about people I'd mentored, performance reviews I'd conducted, difficult conversations I'd had to have.<\/p>\n

It was, honestly, closer to a good interview than a writing exercise.<\/p>\n

And that's where things got interesting. Because when you're forced to articulate the full story - not just "stabilised delivery" but "inherited a failing rebuild with two departing developers, recruited a new team, introduced structured communication, and regained executive confidence to the point where the CEO stopped attending our update meetings" - you realise how much you've been underselling yourself.<\/p>\n

I found myself explaining how I rearchitected a marketing platform from hard-coded campaign types that took months to deliver into a config-driven system that cut that to two to four weeks. How I walked into a startup with no CTO, no engineering process, and an agency-built codebase, and built the entire function from scratch. How I ended up as the sole technical and product lead across two products worth two million dollars in combined annual revenue, after successive restructures stripped away every other support role around me.<\/p>\n

None of that was on my original resume. Not really. The facts were there in outline, but the impact was buried under vague, cautious language.<\/p>\n

What came out the other side<\/h2>\n

Claude produced two separate resumes - one aimed at engineering manager roles, the other at senior technical lead positions. Same career history, but framed very differently.<\/p>\n

The engineering manager version leads with a leadership capabilities section that front-loads hiring, performance management, mentoring, and delivery practices before getting into the role history. It's designed to get past the keyword filters that have been screening me out, while telling a coherent story about someone who's been doing engineering management for years under titles that didn't reflect the scope.<\/p>\n

The technical lead version leads with the tech stack and puts the architectural decisions, system rescues, and hands-on engineering front and centre. It reads as a strong individual contributor who leads from the front.<\/p>\n

Both are significantly longer and more detailed than what I started with. But every bullet point has a concrete claim behind it - a number, a before-and-after, a specific outcome. That's the difference between a resume that describes responsibilities and one that demonstrates impact.<\/p>\n

What I actually learned<\/h2>\n

The exercise surfaced a few things I hadn't fully reckoned with.<\/p>\n

First, I'd been protecting companies that no longer need protecting. I was writing carefully neutral descriptions of situations that were, frankly, messy. Stalled rebuilds, overpromised clients, departing teams, repeated restructures. The instinct is to smooth all of that over. But the mess is the story. Walking into chaos and creating order is the most valuable thing on my resume, and I was barely mentioning it.<\/p>\n

Second, I'd been assuming that the reader would infer impact from context. They won't. If you grew a client base to 750 agencies across three markets, you need to say that. If you cut feature delivery time from months to weeks, you need to say that. The reader isn't going to do the maths for you.<\/p>\n

Third - and this is the one that connects back to my earlier post about the title trap<\/a> - I'd been letting my job titles frame the narrative instead of framing it myself. Claude pushed me to describe what I actually did, not what the contract said. That shift in framing changed everything about how the experience reads.<\/p>\n

A note on using AI for this<\/h2>\n

I want to be straightforward about something: I didn't ask Claude to fabricate anything. Every claim in both resumes is true and I could back it up in an interview. What Claude did was act as an interviewer - pulling out details I wouldn't have thought to include, asking follow-up questions that forced me to be specific, and then structuring the result in a way that's optimised for how resumes are actually read in 2026.<\/p>\n

I should also be clear: I didn't take what Claude produced and submit it unchanged. The output was a strong draft, but it was still a draft. I read through both versions carefully, adjusted phrasing that didn't sound like me, toned down anything that felt overstated, and made sure the final document was something I'd be comfortable defending line by line. AI is a useful collaborator for this kind of work, but your resume represents you - not your tools. Final editorial control matters.<\/p>\n

Could I have done this myself? Probably, eventually. But there's something about being interviewed - even by an AI - that bypasses the instinct to be modest. When someone asks you directly "what was broken and what did you fix?", you answer honestly. When you're writing about yourself, you hedge.<\/p>\n

I don't know yet whether these new resumes will change my results. I'll find out soon enough. But for the first time in two months, I feel like my CV actually represents what I've done - not just where I've been.<\/p>\n

If you're in a similar position - experienced but struggling to land interviews - I'd genuinely recommend trying this approach. Not because AI is magic, but because the interview format forces you to say out loud what you've been too careful to write down. And sometimes that's all it takes.<\/p>\n

Email a comment<\/a><\/p>", "summary": "

I've been job hunting for about two months now. If you've read my earlier posts, you'll know it hasn't been smooth. The rejections have been consistent, the feedback generic, and the pattern frustratingly clear: my experience isn't the problem - my resume is.<\/p>\n

That's a hard thing to admit when you've spent weeks refining it. But the evidence was difficult to ignore. Roles I was genuinely qualified for were filtering me out before a human ever read a word. And when I did get through to a screening call, the outcome was the same polite, non-specific rejection that tells you nothing useful.<\/p>\n

So I tried something different. I sat down with Claude<\/a> - Anthropic's AI assistant - and asked it to help me rewrite my resume. What I didn't expect was how the process would unfold.<\/p>\n

The resume I started with<\/h2>\n

My original resume was pretty good. It listed my roles, my titles, my skills. It had bullet points that described what I did at each company. It was accurate - but it was completely failing to land.<\/p>\n

The problem, I think, is that I wrote it the way most of us write resumes: as a factual record. Here's where I worked, here's what my title was, here's a sanitised summary of my responsibilities. It read like a job description, not a story. And in a market where your CV has about six seconds to make an impression - assuming it gets past the ATS at all - "accurate but unremarkable" is a death sentence.<\/p>\n

The interview<\/h2>\n

I expected Claude to take my resume, sprinkle some stronger verbs on it, and hand it back. Instead, it started asking questions. A lot of questions.<\/p>\n

Not surface-level ones either. It wanted to know what was actually broken when I joined Company X<\/em>. How bad was the codebase? What did the team look like? What specific changes did I make, and what happened as a result? It asked about team sizes, revenue figures, client numbers, reporting lines. It pushed on the gap between my job titles and what I was actually doing. It asked about people I'd mentored, performance reviews I'd conducted, difficult conversations I'd had to have.<\/p>\n

It was, honestly, closer to a good interview than a writing exercise.<\/p>\n

And that's where things got interesting. Because when you're forced to articulate the full story - not just "stabilised delivery" but "inherited a failing rebuild with two departing developers, recruited a new team, introduced structured communication, and regained executive confidence to the point where the CEO stopped attending our update meetings" - you realise how much you've been underselling yourself.<\/p>\n

I found myself explaining how I rearchitected a marketing platform from hard-coded campaign types that took months to deliver into a config-driven system that cut that to two to four weeks. How I walked into a startup with no CTO, no engineering process, and an agency-built codebase, and built the entire function from scratch. How I ended up as the sole technical and product lead across two products worth two million dollars in combined annual revenue, after successive restructures stripped away every other support role around me.<\/p>\n

None of that was on my original resume. Not really. The facts were there in outline, but the impact was buried under vague, cautious language.<\/p>\n

What came out the other side<\/h2>\n

Claude produced two separate resumes - one aimed at engineering manager roles, the other at senior technical lead positions. Same career history, but framed very differently.<\/p>\n

The engineering manager version leads with a leadership capabilities section that front-loads hiring, performance management, mentoring, and delivery practices before getting into the role history. It's designed to get past the keyword filters that have been screening me out, while telling a coherent story about someone who's been doing engineering management for years under titles that didn't reflect the scope.<\/p>\n

The technical lead version leads with the tech stack and puts the architectural decisions, system rescues, and hands-on engineering front and centre. It reads as a strong individual contributor who leads from the front.<\/p>\n

Both are significantly longer and more detailed than what I started with. But every bullet point has a concrete claim behind it - a number, a before-and-after, a specific outcome. That's the difference between a resume that describes responsibilities and one that demonstrates impact.<\/p>\n

What I actually learned<\/h2>\n

The exercise surfaced a few things I hadn't fully reckoned with.<\/p>\n

First, I'd been protecting companies that no longer need protecting. I was writing carefully neutral descriptions of situations that were, frankly, messy. Stalled rebuilds, overpromised clients, departing teams, repeated restructures. The instinct is to smooth all of that over. But the mess is the story. Walking into chaos and creating order is the most valuable thing on my resume, and I was barely mentioning it.<\/p>\n

Second, I'd been assuming that the reader would infer impact from context. They won't. If you grew a client base to 750 agencies across three markets, you need to say that. If you cut feature delivery time from months to weeks, you need to say that. The reader isn't going to do the maths for you.<\/p>\n

Third - and this is the one that connects back to my earlier post about the title trap<\/a> - I'd been letting my job titles frame the narrative instead of framing it myself. Claude pushed me to describe what I actually did, not what the contract said. That shift in framing changed everything about how the experience reads.<\/p>\n

A note on using AI for this<\/h2>\n

I want to be straightforward about something: I didn't ask Claude to fabricate anything. Every claim in both resumes is true and I could back it up in an interview. What Claude did was act as an interviewer - pulling out details I wouldn't have thought to include, asking follow-up questions that forced me to be specific, and then structuring the result in a way that's optimised for how resumes are actually read in 2026.<\/p>\n

I should also be clear: I didn't take what Claude produced and submit it unchanged. The output was a strong draft, but it was still a draft. I read through both versions carefully, adjusted phrasing that didn't sound like me, toned down anything that felt overstated, and made sure the final document was something I'd be comfortable defending line by line. AI is a useful collaborator for this kind of work, but your resume represents you - not your tools. Final editorial control matters.<\/p>\n

Could I have done this myself? Probably, eventually. But there's something about being interviewed - even by an AI - that bypasses the instinct to be modest. When someone asks you directly "what was broken and what did you fix?", you answer honestly. When you're writing about yourself, you hedge.<\/p>\n

I don't know yet whether these new resumes will change my results. I'll find out soon enough. But for the first time in two months, I feel like my CV actually represents what I've done - not just where I've been.<\/p>\n

If you're in a similar position - experienced but struggling to land interviews - I'd genuinely recommend trying this approach. Not because AI is magic, but because the interview format forces you to say out loud what you've been too careful to write down. And sometimes that's all it takes.<\/p>\n

Email a comment<\/a><\/p>", "date_published": "2026-03-31T00:00:00+10:00", "date_modified": "2026-03-31T00:00:00+10:00", "authors": [{ "name": "Phil Stephens" }], "tags": [ ] }, { "id": "https://philstephens.com/109", "title": "Laravel's Terminable Middleware: Run Code After the Response", "url": "https://philstephens.com/blog/laravels-terminable-middleware-run-code-after-the-response", "content_html": "

Most Laravel middleware runs before the response is sent to the browser. You check authentication, validate CSRF tokens, set headers. The request comes in, your middleware does its thing, and the response goes out. But some work doesn't need to happen before the response. It just needs to happen.<\/p>\n

Laravel's terminable middleware lets you run code after<\/em> the response has been sent to the client. The user gets their page, and your application quietly finishes up in the background.<\/p>\n

What terminable middleware actually does<\/h2>\n

A standard middleware has a handle()<\/code> method. A terminable middleware adds a terminate()<\/code> method. The difference is when<\/em> each runs in the PHP lifecycle.<\/p>\n

When a request hits your Laravel app, the HTTP kernel boots the application, runs the middleware pipeline, executes the controller, and builds a response. That response is sent to the client. In a traditional PHP-FPM setup, that would normally be the end of the script's life. But Laravel's HTTP kernel calls terminate()<\/code> on the application after sending the response, which in turn calls terminate()<\/code> on any middleware that defines it.<\/p>\n

With PHP-FPM, the fastcgi_finish_request()<\/code> function is what makes this possible. It flushes the response to the web server, closing the connection to the client, but the PHP process keeps running. Any code after that point executes without the user waiting for it. Laravel calls this function internally before running the termination callbacks.<\/p>\n

The result: your user gets a fast response, and your app does its housekeeping afterwards.<\/p>\n

A real example: visit tracking<\/h2>\n

On this site, I track page visits for anonymous users. That means a database write on every request. It's a cheap operation, but there's no reason the visitor should wait for it. The visit data doesn't affect the response at all.<\/p>\n

Here's the middleware:<\/p>\n

namespace<\/span> <\/span>Privateer\\Basecms\\Http\\Middleware<\/span>;<\/span><\/span>\n<\/span>\nuse<\/span> <\/span>Closure<\/span>;<\/span><\/span>\nuse<\/span> <\/span>Illuminate\\Http\\Request<\/span>;<\/span><\/span>\nuse<\/span> <\/span>Privateer\\Basecms\\Services\\VisitTrackingService<\/span>;<\/span><\/span>\nuse<\/span> <\/span>Symfony\\Component\\HttpFoundation\\Response<\/span>;<\/span><\/span>\n<\/span>\nclass<\/span> <\/span>TrackWebsiteVisits<\/span><\/span>\n{<\/span><\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>__construct<\/span>(<\/span>private<\/span> <\/span>VisitTrackingService<\/span> $visitTrackingService) {}<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>handle<\/span>(<\/span>Request<\/span> $request, <\/span>Closure<\/span> $next)<\/span>:<\/span> <\/span>Response<\/span><\/span>\n    {<\/span><\/span>\n        <\/span>return<\/span> $next($request);<\/span><\/span>\n    }<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>terminate<\/span>(<\/span>Request<\/span> $request, <\/span>Response<\/span> $response)<\/span>:<\/span> <\/span>void<\/span><\/span>\n    {<\/span><\/span>\n        <\/span>if<\/span> (<\/span>!<\/span> <\/span>config<\/span>(<\/span>'basecms.visits.track_visits'<\/span>)) {<\/span><\/span>\n            <\/span>return<\/span>;<\/span><\/span>\n        }<\/span><\/span>\n<\/span>\n        <\/span>if<\/span> ($request<\/span>-><\/span>user<\/span>()) {<\/span><\/span>\n            <\/span>return<\/span>;<\/span><\/span>\n        }<\/span><\/span>\n<\/span>\n        <\/span>$this<\/span>-><\/span>visitTrackingService<\/span>-><\/span>trackVisit<\/span>($request);<\/span><\/span>\n    }<\/span><\/span>\n}<\/span><\/span>\n<\/span><\/code><\/pre>\n
The handle()<\/code> method does nothing. It just passes the request along. All the real work happens in terminate()<\/code>, which runs after the response has already been sent. It checks whether tracking is enabled, skips authenticated users, and then records the visit.<\/p>\n
The tracking service itself does a simple Visit::create()<\/code> with the path, method, IP address, session ID, and user agent. That database insert now happens entirely outside the request\/response cycle.<\/p>\n
Other good candidates<\/h2>\n
Terminable middleware works well for any side-effect that doesn't influence the response.<\/p>\n
Logging and metrics.<\/strong> If you're recording response times, status codes, or request metadata to an external service like Datadog or a logging pipeline, you want the full picture (including the response status) but you don't want the logging call to slow down the response. A terminate()<\/code> method receives both the Request<\/code> and Response<\/code> objects, so you have everything you need.<\/p>\n
Session cleanup or cookie bookkeeping.<\/strong> If you need to write audit records about session activity or update "last seen" timestamps, these don't affect what the user sees. Deferring them to termination keeps the perceived response time lower.<\/p>\n
Preserving state between handle() and terminate()<\/h2>\n
In the visit tracking example, handle()<\/code> doesn't do anything, so there's no state to carry over. But sometimes you'll want to capture something during handle()<\/code> and use it in terminate()<\/code>. Timing a request is the classic case: you'd start a timer in handle()<\/code> and record the elapsed time in terminate()<\/code>.<\/p>\n
There's a catch. By default, Laravel resolves a fresh instance of the middleware for terminate()<\/code>. Any properties you set in handle()<\/code> won't be there.<\/p>\n
The fix is to register the middleware as a singleton in your AppServiceProvider<\/code>:<\/p>\n
use<\/span> <\/span>App\\Http\\Middleware\\TimingMiddleware<\/span>;<\/span><\/span>\n<\/span>\npublic<\/span> <\/span>function<\/span> <\/span>register<\/span>()<\/span>:<\/span> <\/span>void<\/span><\/span>\n{<\/span><\/span>\n    <\/span>$this<\/span>-><\/span>app<\/span>-><\/span>singleton<\/span>(<\/span>TimingMiddleware<\/span>::class<\/span>);<\/span><\/span>\n}<\/span><\/span>\n<\/span><\/code><\/pre>\n
This tells the container to reuse the same instance, so properties set during handle()<\/code> are still available when terminate()<\/code> runs:<\/p>\n
class<\/span> <\/span>TimingMiddleware<\/span><\/span>\n{<\/span><\/span>\n    <\/span>private<\/span> <\/span>float<\/span> $startTime;<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>handle<\/span>(<\/span>Request<\/span> $request, <\/span>Closure<\/span> $next)<\/span>:<\/span> <\/span>Response<\/span><\/span>\n    {<\/span><\/span>\n        <\/span>$this<\/span>-><\/span>startTime <\/span>=<\/span> <\/span>microtime<\/span>(<\/span>true<\/span>);<\/span><\/span>\n<\/span>\n        <\/span>return<\/span> $next($request);<\/span><\/span>\n    }<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>terminate<\/span>(<\/span>Request<\/span> $request, <\/span>Response<\/span> $response)<\/span>:<\/span> <\/span>void<\/span><\/span>\n    {<\/span><\/span>\n        $duration <\/span>=<\/span> <\/span>microtime<\/span>(<\/span>true<\/span>) <\/span>-<\/span> <\/span>$this<\/span>-><\/span>startTime;<\/span><\/span>\n<\/span>\n        <\/span>Log<\/span>::<\/span>info<\/span>(<\/span>'Request duration'<\/span>, [<\/span><\/span>\n            <\/span>'path'<\/span> <\/span>=><\/span> $request<\/span>-><\/span>path<\/span>(),<\/span><\/span>\n            <\/span>'duration_ms'<\/span> <\/span>=><\/span> <\/span>round<\/span>($duration <\/span>*<\/span> <\/span>1000<\/span>, <\/span>2<\/span>),<\/span><\/span>\n            <\/span>'status'<\/span> <\/span>=><\/span> $response<\/span>-><\/span>getStatusCode<\/span>(),<\/span><\/span>\n        ]);<\/span><\/span>\n    }<\/span><\/span>\n}<\/span><\/span>\n<\/span><\/code><\/pre>\n
Without the singleton registration, $this->startTime<\/code> would be uninitialised in terminate()<\/code> and you'd get an error.<\/p>\n
When not to use it<\/h2>\n
Terminable middleware isn't the right tool when the work affects the response. If you need to modify headers, set cookies, or change the response body based on some computation, that has to happen in handle()<\/code>. The response is already gone by the time terminate()<\/code> runs.<\/p>\n
It's also worth noting that the PHP process is still occupied during termination. If your terminate()<\/code> method does something slow, like calling an external API that takes several seconds, it ties up that PHP-FPM worker. For heavy background processing, a queued job is still the better choice. Terminable middleware is best for quick fire-and-forget operations where the overhead of dispatching a job would be more than the work itself.<\/p>\n
Email a comment<\/a><\/p>",
            "summary": "
Most Laravel middleware runs before the response is sent to the browser. You check authentication, validate CSRF tokens, set headers. The request comes in, your middleware does its thing, and the response goes out. But some work doesn't need to happen before the response. It just needs to happen.<\/p>\n
Laravel's terminable middleware lets you run code after<\/em> the response has been sent to the client. The user gets their page, and your application quietly finishes up in the background.<\/p>\n
What terminable middleware actually does<\/h2>\n
A standard middleware has a handle()<\/code> method. A terminable middleware adds a terminate()<\/code> method. The difference is when<\/em> each runs in the PHP lifecycle.<\/p>\n
When a request hits your Laravel app, the HTTP kernel boots the application, runs the middleware pipeline, executes the controller, and builds a response. That response is sent to the client. In a traditional PHP-FPM setup, that would normally be the end of the script's life. But Laravel's HTTP kernel calls terminate()<\/code> on the application after sending the response, which in turn calls terminate()<\/code> on any middleware that defines it.<\/p>\n
With PHP-FPM, the fastcgi_finish_request()<\/code> function is what makes this possible. It flushes the response to the web server, closing the connection to the client, but the PHP process keeps running. Any code after that point executes without the user waiting for it. Laravel calls this function internally before running the termination callbacks.<\/p>\n
The result: your user gets a fast response, and your app does its housekeeping afterwards.<\/p>\n
A real example: visit tracking<\/h2>\n
On this site, I track page visits for anonymous users. That means a database write on every request. It's a cheap operation, but there's no reason the visitor should wait for it. The visit data doesn't affect the response at all.<\/p>\n
Here's the middleware:<\/p>\n
namespace<\/span> <\/span>Privateer\\Basecms\\Http\\Middleware<\/span>;<\/span><\/span>\n<\/span>\nuse<\/span> <\/span>Closure<\/span>;<\/span><\/span>\nuse<\/span> <\/span>Illuminate\\Http\\Request<\/span>;<\/span><\/span>\nuse<\/span> <\/span>Privateer\\Basecms\\Services\\VisitTrackingService<\/span>;<\/span><\/span>\nuse<\/span> <\/span>Symfony\\Component\\HttpFoundation\\Response<\/span>;<\/span><\/span>\n<\/span>\nclass<\/span> <\/span>TrackWebsiteVisits<\/span><\/span>\n{<\/span><\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>__construct<\/span>(<\/span>private<\/span> <\/span>VisitTrackingService<\/span> $visitTrackingService) {}<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>handle<\/span>(<\/span>Request<\/span> $request, <\/span>Closure<\/span> $next)<\/span>:<\/span> <\/span>Response<\/span><\/span>\n    {<\/span><\/span>\n        <\/span>return<\/span> $next($request);<\/span><\/span>\n    }<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>terminate<\/span>(<\/span>Request<\/span> $request, <\/span>Response<\/span> $response)<\/span>:<\/span> <\/span>void<\/span><\/span>\n    {<\/span><\/span>\n        <\/span>if<\/span> (<\/span>!<\/span> <\/span>config<\/span>(<\/span>'basecms.visits.track_visits'<\/span>)) {<\/span><\/span>\n            <\/span>return<\/span>;<\/span><\/span>\n        }<\/span><\/span>\n<\/span>\n        <\/span>if<\/span> ($request<\/span>-><\/span>user<\/span>()) {<\/span><\/span>\n            <\/span>return<\/span>;<\/span><\/span>\n        }<\/span><\/span>\n<\/span>\n        <\/span>$this<\/span>-><\/span>visitTrackingService<\/span>-><\/span>trackVisit<\/span>($request);<\/span><\/span>\n    }<\/span><\/span>\n}<\/span><\/span>\n<\/span><\/code><\/pre>\n
The handle()<\/code> method does nothing. It just passes the request along. All the real work happens in terminate()<\/code>, which runs after the response has already been sent. It checks whether tracking is enabled, skips authenticated users, and then records the visit.<\/p>\n
The tracking service itself does a simple Visit::create()<\/code> with the path, method, IP address, session ID, and user agent. That database insert now happens entirely outside the request\/response cycle.<\/p>\n
Other good candidates<\/h2>\n
Terminable middleware works well for any side-effect that doesn't influence the response.<\/p>\n
Logging and metrics.<\/strong> If you're recording response times, status codes, or request metadata to an external service like Datadog or a logging pipeline, you want the full picture (including the response status) but you don't want the logging call to slow down the response. A terminate()<\/code> method receives both the Request<\/code> and Response<\/code> objects, so you have everything you need.<\/p>\n
Session cleanup or cookie bookkeeping.<\/strong> If you need to write audit records about session activity or update "last seen" timestamps, these don't affect what the user sees. Deferring them to termination keeps the perceived response time lower.<\/p>\n
Preserving state between handle() and terminate()<\/h2>\n
In the visit tracking example, handle()<\/code> doesn't do anything, so there's no state to carry over. But sometimes you'll want to capture something during handle()<\/code> and use it in terminate()<\/code>. Timing a request is the classic case: you'd start a timer in handle()<\/code> and record the elapsed time in terminate()<\/code>.<\/p>\n
There's a catch. By default, Laravel resolves a fresh instance of the middleware for terminate()<\/code>. Any properties you set in handle()<\/code> won't be there.<\/p>\n
The fix is to register the middleware as a singleton in your AppServiceProvider<\/code>:<\/p>\n
use<\/span> <\/span>App\\Http\\Middleware\\TimingMiddleware<\/span>;<\/span><\/span>\n<\/span>\npublic<\/span> <\/span>function<\/span> <\/span>register<\/span>()<\/span>:<\/span> <\/span>void<\/span><\/span>\n{<\/span><\/span>\n    <\/span>$this<\/span>-><\/span>app<\/span>-><\/span>singleton<\/span>(<\/span>TimingMiddleware<\/span>::class<\/span>);<\/span><\/span>\n}<\/span><\/span>\n<\/span><\/code><\/pre>\n
This tells the container to reuse the same instance, so properties set during handle()<\/code> are still available when terminate()<\/code> runs:<\/p>\n
class<\/span> <\/span>TimingMiddleware<\/span><\/span>\n{<\/span><\/span>\n    <\/span>private<\/span> <\/span>float<\/span> $startTime;<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>handle<\/span>(<\/span>Request<\/span> $request, <\/span>Closure<\/span> $next)<\/span>:<\/span> <\/span>Response<\/span><\/span>\n    {<\/span><\/span>\n        <\/span>$this<\/span>-><\/span>startTime <\/span>=<\/span> <\/span>microtime<\/span>(<\/span>true<\/span>);<\/span><\/span>\n<\/span>\n        <\/span>return<\/span> $next($request);<\/span><\/span>\n    }<\/span><\/span>\n<\/span>\n    <\/span>public<\/span> <\/span>function<\/span> <\/span>terminate<\/span>(<\/span>Request<\/span> $request, <\/span>Response<\/span> $response)<\/span>:<\/span> <\/span>void<\/span><\/span>\n    {<\/span><\/span>\n        $duration <\/span>=<\/span> <\/span>microtime<\/span>(<\/span>true<\/span>) <\/span>-<\/span> <\/span>$this<\/span>-><\/span>startTime;<\/span><\/span>\n<\/span>\n        <\/span>Log<\/span>::<\/span>info<\/span>(<\/span>'Request duration'<\/span>, [<\/span><\/span>\n            <\/span>'path'<\/span> <\/span>=><\/span> $request<\/span>-><\/span>path<\/span>(),<\/span><\/span>\n            <\/span>'duration_ms'<\/span> <\/span>=><\/span> <\/span>round<\/span>($duration <\/span>*<\/span> <\/span>1000<\/span>, <\/span>2<\/span>),<\/span><\/span>\n            <\/span>'status'<\/span> <\/span>=><\/span> $response<\/span>-><\/span>getStatusCode<\/span>(),<\/span><\/span>\n        ]);<\/span><\/span>\n    }<\/span><\/span>\n}<\/span><\/span>\n<\/span><\/code><\/pre>\n
Without the singleton registration, $this->startTime<\/code> would be uninitialised in terminate()<\/code> and you'd get an error.<\/p>\n
When not to use it<\/h2>\n
Terminable middleware isn't the right tool when the work affects the response. If you need to modify headers, set cookies, or change the response body based on some computation, that has to happen in handle()<\/code>. The response is already gone by the time terminate()<\/code> runs.<\/p>\n
It's also worth noting that the PHP process is still occupied during termination. If your terminate()<\/code> method does something slow, like calling an external API that takes several seconds, it ties up that PHP-FPM worker. For heavy background processing, a queued job is still the better choice. Terminable middleware is best for quick fire-and-forget operations where the overhead of dispatching a job would be more than the work itself.<\/p>\n
Email a comment<\/a><\/p>",
            "date_published": "2026-03-30T00:00:00+10:00",
            "date_modified": "2026-03-30T00:00:00+10:00",
            "authors": [{ "name": "Phil Stephens" }],
            "tags": [  ]
        },
        {
            "id": "https://philstephens.com/107",
            "title": "The Title Trap: What a Decade of \"Wrong\" Job Titles Taught Me About Career Progression",
            "url": "https://philstephens.com/blog/the-title-trap-what-a-decade-of-wrong-job-titles-taught-me-about-career-progression",
            "content_html": "
I've spent the better part of a decade leading engineering teams, hiring developers, running sprint ceremonies, conducting performance reviews, and making the kind of decisions that shape products and people's careers. By any reasonable measure, I've been doing engineering management for years.<\/p>\n
But my CV doesn't say "Engineering Manager." And right now, that's a problem.<\/p>\n
The roles that didn't come with the "right" name<\/h2>\n
Across startups, scale-ups, and agencies, I've held titles like Development Lead, Technical Director, and Technical Lead. At each of those companies, titles were an afterthought - something scribbled into a contract and never thought about again. What mattered was the work: shipping products, growing teams, unblocking people, and keeping the lights on.<\/p>\n
I didn't push back. Honestly, I didn't think I needed to. The work spoke for itself, or so I assumed.<\/p>\n
That assumption was wrong.<\/p>\n
The wall<\/h2>\n
When I started actively pursuing Engineering Manager roles, the rejections came quickly and consistently. The feedback, when I got any, circled around the same theme: lack of experience<\/em>. Not a lack of skill, not a failed interview - just a title mismatch that meant I never got to the interview at all.<\/p>\n
The uncomfortable truth is that many companies now rely on AI-driven applicant tracking systems that parse your CV long before a human ever sees it. These systems are pattern-matching machines. They're looking for keywords, and "Technical Lead" doesn't trigger the same signals as "Engineering Manager" - even when the underlying experience is identical. By the time a recruiter reviews the shortlist, you're already filtered out.<\/p>\n
It's frustrating. But it's also the reality of how hiring works in 2026.<\/p>\n
What I'd do differently (for what it's worth)<\/h2>\n
I clearly haven't cracked the code here - if I had, I'd be writing this from my Engineering Manager desk. But looking back, there are a few things I'd tell my earlier self. Take them for what they are: one person's hindsight, not a playbook.<\/p>\n
Negotiate the title, not just the salary.<\/strong> At smaller companies, titles are often flexible precisely because they're seen as unimportant. That's your leverage. If you're doing the job of an engineering manager, ask for the title. It costs the company nothing and it costs you everything not to have it.<\/p>\n
Document your scope in the language the market uses.<\/strong> Even if your company calls you a "Lead," make sure your CV translates your responsibilities into terms the broader industry recognises. "Managed a team of eight engineers" lands differently than "led technical delivery."<\/p>\n
Pay attention to where the industry is heading, not just where your company is today.<\/strong> Startups and agencies often have their own vocabulary. That's fine internally, but your career extends beyond any single company. The market doesn't owe you the benefit of the doubt.<\/p>\n
Where I am now<\/h2>\n
I won't pretend this hasn't been humbling. After years of increasing responsibility, I'm now considering roles that might look like a lateral move - or even a step sideways - on paper. But I've made peace with that. Sometimes the fastest route to where you want to be isn't a straight line. If taking a role with the "right" title for a year or two is what it takes to unlock the next chapter, then that's a pragmatic decision, not a defeat.<\/p>\n
The experience doesn't disappear just because the title didn't match. I know what I've done. The challenge now is making sure the next opportunity reflects it - starting with the name on the tin.<\/p>\n
If this sounds familiar<\/h2>\n
If you're early in your career, or somewhere in the middle like I am, take this as a gentle nudge: titles matter more than you think they do. Not because they define your capability, but because they define how the market sees you. And in a hiring landscape increasingly shaped by automation and keyword matching, perception is the first gate you have to pass through.<\/p>\n
That said, this is just my experience and my opinion. I'm still figuring this out in real time, and I'm well aware there are people who've navigated this far more gracefully than I have.<\/p>\n
If you see it differently - or if you've been through something similar and found an approach that worked - I'd love to hear from you. Drop me an email. I'm always up for a conversation, especially one that challenges how I'm thinking about this.<\/p>\n
Email a comment<\/a><\/p>",
            "summary": "
I've spent the better part of a decade leading engineering teams, hiring developers, running sprint ceremonies, conducting performance reviews, and making the kind of decisions that shape products and people's careers. By any reasonable measure, I've been doing engineering management for years.<\/p>\n
But my CV doesn't say "Engineering Manager." And right now, that's a problem.<\/p>\n
The roles that didn't come with the "right" name<\/h2>\n
Across startups, scale-ups, and agencies, I've held titles like Development Lead, Technical Director, and Technical Lead. At each of those companies, titles were an afterthought - something scribbled into a contract and never thought about again. What mattered was the work: shipping products, growing teams, unblocking people, and keeping the lights on.<\/p>\n
I didn't push back. Honestly, I didn't think I needed to. The work spoke for itself, or so I assumed.<\/p>\n
That assumption was wrong.<\/p>\n
The wall<\/h2>\n
When I started actively pursuing Engineering Manager roles, the rejections came quickly and consistently. The feedback, when I got any, circled around the same theme: lack of experience<\/em>. Not a lack of skill, not a failed interview - just a title mismatch that meant I never got to the interview at all.<\/p>\n
The uncomfortable truth is that many companies now rely on AI-driven applicant tracking systems that parse your CV long before a human ever sees it. These systems are pattern-matching machines. They're looking for keywords, and "Technical Lead" doesn't trigger the same signals as "Engineering Manager" - even when the underlying experience is identical. By the time a recruiter reviews the shortlist, you're already filtered out.<\/p>\n
It's frustrating. But it's also the reality of how hiring works in 2026.<\/p>\n
What I'd do differently (for what it's worth)<\/h2>\n
I clearly haven't cracked the code here - if I had, I'd be writing this from my Engineering Manager desk. But looking back, there are a few things I'd tell my earlier self. Take them for what they are: one person's hindsight, not a playbook.<\/p>\n
Negotiate the title, not just the salary.<\/strong> At smaller companies, titles are often flexible precisely because they're seen as unimportant. That's your leverage. If you're doing the job of an engineering manager, ask for the title. It costs the company nothing and it costs you everything not to have it.<\/p>\n
Document your scope in the language the market uses.<\/strong> Even if your company calls you a "Lead," make sure your CV translates your responsibilities into terms the broader industry recognises. "Managed a team of eight engineers" lands differently than "led technical delivery."<\/p>\n
Pay attention to where the industry is heading, not just where your company is today.<\/strong> Startups and agencies often have their own vocabulary. That's fine internally, but your career extends beyond any single company. The market doesn't owe you the benefit of the doubt.<\/p>\n
Where I am now<\/h2>\n
I won't pretend this hasn't been humbling. After years of increasing responsibility, I'm now considering roles that might look like a lateral move - or even a step sideways - on paper. But I've made peace with that. Sometimes the fastest route to where you want to be isn't a straight line. If taking a role with the "right" title for a year or two is what it takes to unlock the next chapter, then that's a pragmatic decision, not a defeat.<\/p>\n
The experience doesn't disappear just because the title didn't match. I know what I've done. The challenge now is making sure the next opportunity reflects it - starting with the name on the tin.<\/p>\n
If this sounds familiar<\/h2>\n
If you're early in your career, or somewhere in the middle like I am, take this as a gentle nudge: titles matter more than you think they do. Not because they define your capability, but because they define how the market sees you. And in a hiring landscape increasingly shaped by automation and keyword matching, perception is the first gate you have to pass through.<\/p>\n
That said, this is just my experience and my opinion. I'm still figuring this out in real time, and I'm well aware there are people who've navigated this far more gracefully than I have.<\/p>\n
If you see it differently - or if you've been through something similar and found an approach that worked - I'd love to hear from you. Drop me an email. I'm always up for a conversation, especially one that challenges how I'm thinking about this.<\/p>\n
Email a comment<\/a><\/p>",
            "date_published": "2026-03-27T00:00:00+10:00",
            "date_modified": "2026-03-27T00:00:00+10:00",
            "authors": [{ "name": "Phil Stephens" }],
            "tags": [  ]
        },
        {
            "id": "https://philstephens.com/108",
            "title": "Tracking File Uploads from Filament's MarkdownEditor",
            "url": "https://philstephens.com/blog/tracking-file-uploads-from-filaments-markdowneditor",
            "content_html": "
The MarkdownEditor<\/code> component that ships with Filament<\/a> handles file uploads out of the box. Drop an image in, it gets stored to disk, and a URL is inserted into your markdown. Simple enough.<\/p>\n
But what happens to those files after that? There's no database record. No way to know which post an image belongs to. No audit trail of who uploaded what. If you delete a post, its images quietly become orphans sitting on your S3 bucket forever.<\/p>\n
I ran into this while building a Laravel package that uses Filament to manage blog content. I wanted every uploaded file tracked in the database, linked back to its parent post or page, and attributed to the user who uploaded it. The MarkdownEditor<\/code> component has the hooks to make this work; you just need to wire them up.<\/p>\n
The hooks Filament gives you<\/h2>\n
MarkdownEditor<\/code> exposes three methods for customising file attachment behaviour:<\/p>\n