About Me
Thesis
Vibe Coding
Agentic Engineering
What It Looks Like
Build me a billing retry system with retries, emails, admin UI, and tests.
The agent generates models, jobs, notifications, migrations, and some happy-path tests.
Midway through, requirements change: different retry rules per plan, no duplicate emails, and finance wants auditability.
Now the code technically exists, but the design no longer matches the real problem.
Concrete Failure Mode
Ops
"Why did we retry twice in 10 minutes?"
Support
"Customer email says attempt #3, admin still shows attempt #2."
Engineering
"We have tests, but only for the happy path we generated first."
To Be Fair
Definition
Input
Requirements, constraints, architecture, order of work, validation rules.
Execution
Scoped prompts, clean context, bounded tasks, explicit expectations.
Output
Reliable change you can review, test, ship, and maintain with confidence.
Workflow
Real-World Example
Feature Must
Hidden Complexity
Step 1
# REQS
Feature:
Implement subscription payment retry flow for failed renewals.
Core Requirements:
- Failed renewals must create a retry record.
- Retry attempts must follow configured backoff intervals.
- Customers must receive an email after each failed retry.
- Admins must see retry state and next scheduled attempt.
Design:
- Subscription
- PaymentAttempt
- RetrySchedule
- RetryPaymentAction
- NotifyCustomerAboutFailedPaymentAction
- RetryPaymentJob
- BillingRetryService
Validation:
- Feature tests for scheduling and notifications
- Unit tests for backoff calculation
- Integration tests for queue orchestration
Steps 2 and 3
Planning Prompt
Given REQS.md, produce a step-by-step implementation plan.
Do not write code.
The plan should cover implementation steps and the test suite needed.
Prefer a TDD flow: define strong happy and unhappy path tests first,
then implement the smallest, simplest solution that makes them pass.
Use the available MCP tools and relevant skills, and follow the
project's established standards and conventions.
Call out:
- sequencing dependencies
- risk areas
- validation checkpoints
- data model and state transitions
- what should be tested before notifications or UI
What I Challenge in Review Rounds
Are the transitions explicit and durable?
Are retries idempotent and safe under replays?
Does the UI depend on state we have not modeled yet?
Are tests placed before risky integrations and side effects?
Did the agent introduce jobs or orchestration too early?
Step 4
final readonly class BillingRetryService
{
public function __construct(
private CalculateRetryBackoff $backoff,
private RetryPaymentAction $retryPayment,
private NotifyCustomerAboutFailedPaymentAction $notifyCustomer,
) {}
public function handle(PaymentAttempt $attempt): void
{
$schedule = $this->backoff->for($attempt);
RetryPaymentJob::dispatch($attempt->id, $schedule->nextAttemptAt);
}
}
final readonly class RetryPaymentJob implements ShouldQueue
{
public function handle(
LoadPaymentAttempt $loadAttempt,
RetryPaymentAction $retryPayment,
PersistRetryState $persistState,
NotifyCustomerAboutFailedPaymentAction $notifyCustomer,
): void {
$attempt = $loadAttempt->handle($this->paymentAttemptId);
$result = $retryPayment->handle($attempt);
$persistState->handle($attempt, $result);
if ($result->failed()) {
$notifyCustomer->handle($attempt, $result);
}
}
}
Step 5
Review Prompt
Do a deep review of the changed files in git.
Use REQS.md and PLAN.md as the reference for what should exist.
Check for code quality issues, project standards violations,
and edge cases missing in the implementation or test suite.
Use the available MCP tools and relevant skills, and follow the
project's established standards and conventions.
Step 6
Naming and boundaries
Are class responsibilities clean, readable, and maintainable a month from now?
Framework conventions
Does it feel native to the codebase, or does it look generated and slightly off?
Real confidence
Do the tests prove the risky paths, and would I actually be happy to keep this in production?
Production Readiness
it('schedules the next retry using the configured backoff', function () {
Carbon::setTestNow('2026-04-10 10:00:00');
$attempt = PaymentAttempt::factory()->failedRenewal()->create();
app(BillingRetryService::class)->handle($attempt);
expect($attempt->fresh()->retrySchedule)
->next_attempt_at
->toEqual(Carbon::parse('2026-04-13 10:00:00'));
});
You also need observability
Log every retry attempt and gateway response with enough context for support and ops.
Track retry success rate by gateway, plan, and failure reason.
Trigger alerts when customers exceed a threshold of terminal failures.
Make the admin timeline match exactly what happened in the queue.
Adoption
Vibe Coding Is Fine When
Use Agentic Engineering When
Takeaway