The Problem: Losing Your Place in Prayer

About five years ago, I prayed the rosary daily for a year—at least 365 times. I used a prayer book with a bookmark. It worked—until it didn’t. I’d get interrupted, lose my place, and not know whether I was on the third decade or the fourth. The prayer book also didn’t include the full Bible passages for each mystery, just brief titles. If I wanted to meditate on the actual scripture, I had to look it up separately.

There are also times when you want to pray but don’t have your beads—waiting at an appointment, sitting quietly before Mass, on a lunch break. The rosary is a prayer you can pray anywhere, and a digital companion can make that easier.

Mystery by Mystery solves both problems. It tracks your progress decade by decade—so you never lose your place—and includes a beadless mode so you can pray a rosary wherever you are, at any time.

What the App Does

Decade-by-Decade Tracking

The core of the app is a simple counter. Large +/- buttons advance you through the five decades of the rosary. The current mystery name, its scripture passage, and your position are always visible. If you need to stop after the second decade and come back later, your place is saved. No more lost bookmarks.

This is the feature I built the app around. You don’t have to pray all five decades in one sitting. Life interrupts. Mystery by Mystery lets you pick up exactly where you left off.

Full Scripture Passages

Each of the twenty mysteries includes the full Bible passage for meditation—not just a title like “The Agony in the Garden,” but the actual verses. Two public domain translations are available: the Catholic Public Domain Version (default) and the Douay-Rheims. Scripture text is collapsible so it’s there when you want it and out of the way when you don’t.

Beadless Mode

A virtual bead counter lets you pray without a physical rosary. The app tracks each Hail Mary within a decade, so you always know where you are. This is what makes the rosary truly portable—you can pray it with just your phone.

Prayer Text

All the prayers are built in: the Apostles’ Creed, Our Father, Hail Mary, Glory Be, Hail Holy Queen, and the optional Fatima Prayer. Opening and closing prayer sections are collapsible and remember your preference. If you have the prayers memorized, collapse them. If you want the text visible, expand them. The app supports both traditional language (”thee/thy”) and modern language (”you/your”).

Two Progression Modes

Daily Schedule follows the traditional Catholic liturgical calendar—Joyful Mysteries on Monday, Sorrowful on Tuesday, and so on. Continuous Cycle moves through all four mystery sets in order: Joyful, Luminous, Sorrowful, Glorious, then repeats. Choose whichever fits your practice.

History and Statistics

Every completed rosary is logged. The history screen shows your completions grouped by date, with statistics: total rosaries prayed, breakdown by mystery set, and current streak. Export your history as CSV or JSON if you want to keep records outside the app.

Designed for Accessibility

The primary audience for a rosary app skews older. The design reflects that: tap targets are 60+ points, text uses Georgia serif for readability, color schemes all pass WCAG AA contrast standards, and dark mode is fully supported. Three color themes—Parchment (warm prayer book aesthetic), Chapel (stone and stained glass), and Garden (peaceful greens)—let you choose what feels right.

Who It’s For

If you pray the rosary and have ever lost your place, wanted the scripture text at hand, or wished you could pray without beads, this app is for you. It’s simple by design. No social features, no gamification, no accounts. Just a quiet tool for prayer.

Download: iOS & macOS App Store | Google Play Store | Windows & Linux (GitHub Releases)

Related: PropaneTracker, HayTracker, and DevHours - other Code Pasture apps built with Planning-Driven Development

For the methodology behind building apps with AI, see Planning-Driven Development: The Single Biggest Productivity Multiplier with GenAI Agents.

The Problem: Conversations Everywhere, Visibility Nowhere

If you run an OpenClaw agent, you probably talk to it through WhatsApp, Telegram, Signal, or Discord. That works fine for casual interaction. But the moment you’re running more than one agent—or you want to understand what your agent is actually doing—messaging apps fall short.

Your conversation history is fragmented across platforms. You can’t search across channels. You have zero visibility into what’s happening under the hood: which tools the agent called, what arguments it used, how long execution took, whether it succeeded or failed. Messaging apps show you the output. They don’t show you the process.

And if you’re managing multiple agents—a work assistant on an Azure VM, a home automation bot on a Raspberry Pi, a persona bot running locally—there’s no single place to see them all.

Claw Command fills that gap. It’s a native app that acts as a command center for your OpenClaw fleet.

What the App Does

Fleet Dashboard

The home screen shows all your connected OpenClaw gateways at a glance. Each agent card displays its name, gateway URL, and connection status. Add new agents by entering an OpenClaw gateway URL and completing the device pairing flow. Drag to reorder.

Chat with Deep Observability

This is the core differentiator. You get a full chat interface with real-time WebSocket streaming, but unlike messaging apps, you can see inside each response:

Tool execution blocks expand to show the tool name, arguments passed, live output streaming, execution duration, and success/failure status. When your agent searches the web, queries a database, or calls an API, you see exactly what happened.

Full-Text Search

Every message sent or received through Claw Command syncs to a local SQLite database with FTS5 indexing. Search across all your Claw Command sessions and agents. Filter by agent, role, or date range. Results are ranked by relevance with highlighted snippets. Your Claw Command conversation history becomes a searchable archive.

Multi-Session Management

Each agent supports multiple concurrent sessions. A session drawer lets you switch between conversations. Cross-channel sessions from WhatsApp, Telegram, Discord, and other platforms are visible as read-only previews, so you can see what your agent has been doing across all channels without leaving the app.

Network Discovery

On your local network, Claw Command uses mDNS (DNS-SD) to automatically discover OpenClaw gateways—no manual URL entry needed. It also detects Tailscale VPN status in Settings, which is the recommended way to securely connect to agents running on remote machines.

Export and Import

Export your chat history as CSV or JSON. Import JSON backups to restore data. Manage local storage with configurable message limits.

Technical Highlights

ED25519 Device Authentication

Claw Command doesn’t use passwords. Each device generates an ED25519 keypair on first launch, stored in the platform’s secure keychain (iOS Keychain, Android Keystore, macOS Keychain, etc.). The public key is exchanged during a one-time pairing flow with each OpenClaw gateway. Every subsequent WebSocket connection is authenticated by signing a challenge with the device’s private key.

This means your device is your credential. No passwords to leak, no tokens to rotate. If a device is compromised, you revoke its public key from the gateway.

FTS5 Search Architecture

Full-text search uses SQLite’s FTS5 extension, which runs entirely on-device. Messages are indexed as they arrive over WebSocket. The search implementation supports smart query syntax—phrases, prefix matching, boolean operators—giving you grep-like power over your agent history without any server dependency.

WebSocket Streaming with Offline Support

Messages stream in real-time over WebSocket connections to OpenClaw gateways, but the app doesn’t fall over when connectivity drops. A connection banner shows status changes, a message queue holds outbound messages during disconnection, and reconnection with sync happens automatically when the network returns.

Six Platforms from One Codebase

Claw Command ships on iOS, Android, macOS, Windows, and Linux from a single Flutter codebase. Platform-specific concerns—keychain APIs, window management, edge-to-edge display, icon bundling—are handled individually, but the core architecture is shared.

Challenges Worth Mentioning

Detecting Zombie WebSocket Connections

A WebSocket can be technically open but completely unresponsive—the gateway process hung, the network path silently dropped, or a VPN tunnel stalled. TCP keepalives don’t catch this fast enough. The OpenClaw gateway sends periodic tick events, and Claw Command watches the gap between them. If no tick arrives within twice the expected interval, the client force-closes the socket and triggers reconnection. Without this, the app would sit showing “connected” while nothing was actually getting through.

Message Deduplication on Reconnect

When the app reconnects to an OpenClaw gateway, it fetches recent messages to catch up on anything missed. But some of those messages might already be in the local database from before the disconnect. The app deduplicates by generating signatures from each message’s role and first 200 characters of content, stripping gateway metadata before comparison. This prevents duplicate messages in the chat history without disrupting any sends that were still in flight.

Tool Call State Machine

Tool executions aren’t instant—they can take seconds or minutes. The gateway streams tool call lifecycle events: start creates the tool call entry with a running indicator, update events accumulate partial output, and result finalizes with duration and success/failure status. The UI reflects each state: an animated spinner while running, expandable output as it streams in, and final status with execution time when complete.

Who It’s For

Claw Command is built for OpenClaw power users. If you run one agent and chat with it casually through WhatsApp, you probably don’t need this. But if you run multiple agents, want to understand what’s happening inside your conversations, or need a searchable archive of your agent history across all channels, this is the app.

Download: iOS App Store | Google Play Store | Windows & Linux (GitHub Releases)

Related: PropaneTracker, HayTracker, and DevHours - other Code Pasture apps built with Planning-Driven Development

For the methodology behind building apps with AI, see Planning-Driven Development: The Single Biggest Productivity Multiplier with GenAI Agents.

The Problem

I was building a Flutter macOS app that stores sensitive credentials in the system keychain using flutter_secure_storage (v10.0.0). Every write operation failed with:

PlatformException(Unexpected security result code,
  Code: -34018, Message: A required entitlement isn't present., -34018, null)

Error -34018 is errSecMissingEntitlement — macOS is telling you the app lacks a required entitlement for the keychain operation you’re attempting.

The Rabbit Hole

I spent hours working through every fix suggested by GitHub issues and Stack Overflow:

1. Added keychain-access-groups entitlement to both DebugProfile.entitlements and Release.entitlements:

<key>com.apple.security.keychain-access-groups</key>
<array>
    <string>$(AppIdentifierPrefix)com.example.myApp</string>
</array>

Still failed.

2. Added DEVELOPMENT_TEAM to project.pbxproj so $(AppIdentifierPrefix) resolves correctly:

DEVELOPMENT_TEAM = XXXXXXXXXX;

Verified with codesign -d --entitlements :- that the built binary had the correct resolved entitlement. Still failed.

3. Changed CODE_SIGN_IDENTITY from ad-hoc ("-") to "Apple Development":

CODE_SIGN_IDENTITY = "Apple Development";

Confirmed via codesign -dvv the app was properly signed with a valid Apple Development certificate, correct Team ID, and all entitlements present. Still failed.

4. Tried the MacOsOptions escape hatch — the plugin offers usesDataProtectionKeychain: false to use the legacy keychain, which doesn’t require a provisioning profile:

final storage = const FlutterSecureStorage();
await storage.write(
  key: 'my_key',
  value: 'my_value',
  mOptions: const MacOsOptions(usesDataProtectionKeychain: false),
);

Still failed with the exact same error. This is when Claude Code started reading the plugin’s source code.

The Root Cause: A Key Name Mismatch

The flutter_secure_storage package delegates to a platform-specific plugin on macOS: flutter_secure_storage_darwin (v0.2.0). The Dart side and Swift side disagree on the name of a critical configuration key.

Dart side — MacOsOptions.toMap() produces:

@override
Map<String, String> toMap() => <String, String>{
  ...super.toMap(),
  'usesDataProtectionKeychain': '$usesDataProtectionKeychain',
};

Swift side — FlutterSecureStorageDarwinPlugin.swift reads:

usesDataProtectionKeychain: (options["useDataProtectionKeyChain"] as? String)
    .flatMap { Bool($0) } ?? true,

Spot the difference?

Dart sendsSwift readsKey nameusesDataProtectionKeychainuseDataProtectionKeyChainPrefixuses (with ‘s’)use (no ‘s’)Casingkeychain (lowercase)KeyChain (uppercase C)

These are completely different strings. The Swift code never finds the Dart-supplied option, so it falls through to the default: ?? true. The Data Protection Keychain is always used, regardless of what you set in Dart.

This bug was introduced in v10.0.0 when the iOS and macOS implementations were merged into the unified flutter_secure_storage_darwin package. The original parameter was named useDataProtectionKeyChain (added in v9.2.3), but the Dart-side MacOsOptions class was renamed to usesDataProtectionKeychain without updating the Swift reader.

It’s Not Just One Key

After finding the usesDataProtectionKeychain mismatch, I audited every option key between the Dart AppleOptions.toMap() and the Swift parseCall(). There are actually four mismatches:

The first three mismatches (isInvisible/isHidden, isNegative/isPlaceholder, shouldReturnPersistentReference/persistentReference) are all obscure options that default to null/unset, so they silently no-op. The only one that causes real damage is usesDataProtectionKeychain because it defaults to true when the key isn’t found.

The Fix

Create a subclass that overrides toMap() to add the key name the Swift code actually reads, while keeping the original key for forward-compatibility when the plugin is eventually fixed:

import 'package:flutter_secure_storage/flutter_secure_storage.dart';

/// Workaround for a key-name mismatch in flutter_secure_storage_darwin v0.2.0.
///
/// Dart's MacOsOptions.toMap() emits 'usesDataProtectionKeychain', but the
/// Swift plugin reads 'useDataProtectionKeyChain' (different casing, no 's').
/// This subclass adds the correct key so the option reaches native code,
/// while keeping the original for forward-compatibility.
class FixedMacOsOptions extends MacOsOptions {
  const FixedMacOsOptions({super.usesDataProtectionKeychain});

  @override
  Map<String, String> toMap() {
    final map = super.toMap();
    final value = map['usesDataProtectionKeychain'];
    if (value != null) {
      map['useDataProtectionKeyChain'] = value;
    }
    return map;
  }
}

By keeping both keys in the map, the current buggy Swift code reads useDataProtectionKeyChain, and a future fixed plugin can read usesDataProtectionKeychain. No breakage either way.

Then use it in your secure storage calls:

const macOsOptions = FixedMacOsOptions(usesDataProtectionKeychain: false);

final storage = const FlutterSecureStorage();

// Read
await storage.read(key: 'my_key', mOptions: macOsOptions);

// Write
await storage.write(key: 'my_key', value: 'secret', mOptions: macOsOptions);

// Delete
await storage.delete(key: 'my_key', mOptions: macOsOptions);

With usesDataProtectionKeychain: false actually reaching the native code, the plugin uses the legacy macOS keychain instead of the Data Protection Keychain. The legacy keychain doesn’t require a provisioning profile, so it works with standard development signing.

Add a Unit Test

Since this workaround depends on exact string matching, pin it with a test:

test('toMap includes both Dart and Swift key names', () {
  const options = FixedMacOsOptions(usesDataProtectionKeychain: false);
  final map = options.toMap();

  // Swift plugin (v0.2.0) reads this key:
  expect(map['useDataProtectionKeyChain'], 'false');
  // Dart key kept for forward-compatibility:
  expect(map['usesDataProtectionKeychain'], 'false');
});

Legacy Keychain vs Data Protection Keychain

Using usesDataProtectionKeychain: false is a trade-off worth understanding.

Data Protection Keychain (DPK) is Apple’s recommended path for new apps. It provides iOS-like behavior on macOS with better integration with modern platform protection. However, it requires a provisioning profile, which means either Xcode automatic signing or manual profile management through the Apple Developer portal.

Legacy Keychain works without a provisioning profile and is the practical choice when:

• You’re in early development and haven’t set up provisioning

• You’re building a tool that needs to work with ad-hoc or local-development signing

• The flutter_secure_storage plugin has a bug preventing DPK from working (like this one)

The legacy keychain still encrypts items and scopes access per-app by service name (which flutter_secure_storage sets to the bundle ID by default). Items default to kSecAttrAccessibleWhenUnlocked (only accessible when the device is unlocked) and are not synchronized to iCloud.

If you’re going to production, plan to migrate to DPK once either the plugin fixes the key mismatch or you set up proper provisioning profiles.

Why This Bug Is Hard to Find

1. No error at the Dart level. The option is accepted, serialized, and sent to the native side without complaint.

2. No error at the Swift level. The Swift code doesn’t find the key, silently uses the default, and proceeds — the failure only surfaces later as a keychain access error.

3. The error message is misleading. -34018 says “entitlement missing,” so you naturally focus on entitlements, signing, and provisioning — not on whether the plugin is reading your options correctly.

4. The option name is almost right. usesDataProtectionKeychain vs useDataProtectionKeyChain — you’d need to compare them character by character to notice the difference.

Quick Diagnostic

If you’re unsure whether keychain access works at all, add a smoke test at app startup:

void main() {
  WidgetsFlutterBinding.ensureInitialized(); // Required for platform channels

  _testKeychainAccess();

  runApp(const MyApp());
}

Future<void> _testKeychainAccess() async {
  const options = FixedMacOsOptions(usesDataProtectionKeychain: false);
  const storage = FlutterSecureStorage();
  try {
    await storage.write(key: '_test', value: 'ok', mOptions: options);
    final result = await storage.read(key: '_test', mOptions: options);
    await storage.delete(key: '_test', mOptions: options);
    debugPrint('[KEYCHAIN] diagnostic: ${result == 'ok' ? 'PASS' : 'FAIL'}');
  } catch (e) {
    debugPrint('[KEYCHAIN] diagnostic: FAIL ($e)');
  }
}

Note: WidgetsFlutterBinding.ensureInitialized() must be called before any platform channel operations, including secure storage.

Key Takeaways

1. Error -34018 doesn’t always mean your entitlements are wrong. It can also mean the plugin is silently using the wrong keychain type.

2. MacOsOptions(usesDataProtectionKeychain: false) doesn’t work in flutter_secure_storage_darwin v0.2.0 due to a key name mismatch between Dart and Swift.

3. The mismatch isn’t limited to one key. Four option keys have drifted between Dart and Swift in this plugin version, though only usesDataProtectionKeychain causes visible failures.

4. The fix is a small toMap() override that emits both the old and new key names for forward-compatibility. Pin it with a unit test.

5. When a plugin option seems to have no effect, read the native source. The Dart API and native implementation may have drifted apart, especially after major refactors.

References

• flutter_secure_storage on pub.dev

• GitHub Issue #804: Secure storage crashes with “A required entitlement isn’t present” on MacOS

• Apple Developer Documentation: kSecUseDataProtectionKeychain

• Apple Developer: Sharing access to keychain items among a collection of apps

• Apple Support: Keychain data protection

Discovered while building a Flutter macOS app that stores device credentials in the system keychain. The entire debugging session — from “must be an entitlement issue” to “wait, the plugin has a typo” — took several hours. The four-key mismatch audit was prompted by a security review that asked “are there other drifted keys?” Hopefully this saves you the same trip.

I’ve been following discussions about AI in software development, and I keep noticing something: none of the issues people raise are new.

Time pressure. Cognitive load. Code quality. Performance concerns. Economic reality. The tension between shipping fast and shipping right.

These existed long before AI. They exist now. They’ll exist after.

What changed for me isn’t accountability. It’s feasibility—and time compression so dramatic it feels like a different job.

The Problems That Never Left

The real problems in software development aren’t about AI. They’re about complexity, constraints, and tradeoffs we’ve been navigating for decades.

Domain logic scattered across system layers. Business rules split between UI validation, API handlers, scheduled jobs, application code, and stored procedures. To understand what the system actually does, you trace through five layers. To test it, you need integration tests for everything. This predates AI by decades.

Monoliths that are hard to maintain and deploy. Fragile systems where a change in one area breaks something unrelated. Deployments that require coordination across teams. Code that nobody wants to touch because the blast radius is unknown.

The iron triangle: schedule, quality, scope. Pick two. This constraint—articulated by Steve McConnell and others—hasn’t changed. Every project negotiates between shipping fast, shipping well, and shipping everything. AI doesn’t resolve that tension.

Teams that are understaffed for the work expected. Not enough people, too many priorities, constant context switching. The math never worked, but we shipped anyway.

No system is perfect, including anything I’ve developed. AI didn’t create these problems. But here’s what’s interesting: AI changes one variable in the equation.

What Actually Changed

Here’s what’s different: time collapsed.

I’ve helped others solve problems in 10 minutes that they’d spent days on. Multiple times. Not because I’m smarter, but because I can explore solution spaces faster.

I’m architecting and implementing production systems at a pace I couldn’t achieve before. Not by skipping steps, but by compressing the mechanical work. The thinking still takes the same time. The typing doesn’t.

Days became hours. Hours became minutes. The ceiling moved—what used to require a team, one person can now prototype. What used to take weeks of boilerplate, now takes hours of focused design work.

But here’s what didn’t change: I’m still responsible for the systems I create.

AI needs guidance. AI needs understanding. AI needs someone who knows what “correct” looks like—not just what “runs” looks like.

Code that runs isn’t the same as code that works well. That distinction existed before AI, and it’s even more critical now.

The Accountability Paradox

I keep reading stories about developers who shipped AI-generated code that didn’t work, code they didn’t test, code they didn’t understand. And my reaction is always the same:

Why wouldn’t they have done this anyway?

Developers who ship untested code with AI would ship untested code without AI. Developers who don’t understand what they’re deploying didn’t suddenly start when AI arrived.

AI didn’t lower the bar. It rewards those who were already doing the work well.

The developers getting value from AI are the ones who were already doing the work: understanding requirements, validating implementations, owning their systems. AI accelerates their process. It doesn’t replace their judgment.

What I’ve Found Actually Works

I’m not going to pretend I have all the answers. But I know what works for me because I’ve done it—repeatedly, across different projects and domains.

Planning-Driven Development. The quality of your planning directly determines the quality of your output. I spend hours on planning documents before writing code. It sounds slow. It’s the fastest approach I’ve found.

Example-Driven Development. Working examples that demonstrate the patterns you want. AI learns from examples better than from abstract instructions. So do humans.

Discussing tradeoffs explicitly. Architectural decisions, framework choices, pros and cons of every approach. AI is a surprisingly good collaborator for exploring decision spaces—but only if you engage it that way.

Treating AI as a collaborator, not a replacement. AI works for me. It doesn’t work instead of me. That distinction changes everything about how you interact with these tools.

I’ve written extensively about these approaches elsewhere. The short version: the fundamentals of good software development—planning, testing, understanding your domain, owning your systems—matter more now, not less.

Should I Even Post This?

I almost didn’t write this. There’s so much noise about AI. So many misconceptions. So many people talking past each other.

But maybe that’s exactly why it’s worth saying:

Nothing fundamental changed about what makes software good or bad. The same practices that worked before—planning, testing, understanding, ownership—still work. They just work faster now for those who invest the time to properly leverage GenAI agents.

What changed is what’s possible. The scope of what one person can accomplish expanded dramatically. The speed of iteration accelerated. The barrier to exploring ideas dropped.

But the responsibility stayed exactly where it was. With the developer. With you. With me.

AI won’t do your work for you. If you learn to make it work for you—not instead of you—the results are genuinely astounding.

But that requires doing the work. Same as it ever was.

For the specific methodologies I’ve found effective:

• Planning-Driven Development - Why planning documents are the biggest productivity multiplier

• Example-Driven Development - Using working examples to guide AI

• Taming GenAI Agents with TDD - Tests as guardrails for AI-assisted development

The Problem

When using the share_plus package to share files or text on iOS, you may encounter this crash:

PlatformException(error, sharePositionOrigin: argument must be set,
{{0, 0}, {0, 0}} must be non-zero and within coordinate space of source view:
{{0, 0}, {440, 956}}, null, null)

This occurs when calling Share.shareXFiles() or SharePlus.instance.share() without providing the sharePositionOrigin parameter.

Why This Worked Before

The share_plus package is the standard way to invoke the native share sheet in Flutter apps. On iOS, the share sheet is a UIActivityViewController that presents differently depending on the device:

• iPhone: Modal sheet sliding up from the bottom

• iPad: Popover anchored to a specific point on screen

Because iPads use a popover presentation, iOS needs to know where to anchor the popover arrow. The sharePositionOrigin parameter provides this—a Rect defining the source location.

Historically, this parameter was only required on iPad. iPhone apps could omit it because the modal presentation doesn’t need an anchor point.

What Changed in iOS 26

Apple now validates sharePositionOrigin on all iOS devices, including iPhones.

If you don’t provide a valid non-zero rect, the share sheet crashes with a PlatformException. This was reported to the share_plus team in August 2025 (GitHub issue #3645) and fixed in version 12.0.1.

Why Testing Didn’t Catch It

I had both HayTracker and PropaneTracker in the App Store and Google Play with working export functionality. I tested before release:

• AirDropped exports from both apps to my MacBook

• Saved exports directly on my development iPhone

• Verified exports on Android devices

Everything worked. The crash only appeared after updating my test iPhone to iOS 26.

The issue is timing: I tested on an older iOS version before Apple introduced the stricter validation. Once iOS 26 rolled out, the missing sharePositionOrigin caused crashes for users who had updated.

The Fix

Always provide a sharePositionOrigin parameter:

import 'dart:ui';
import 'package:share_plus/share_plus.dart';

await Share.shareXFiles(
  files,
  subject: 'My Export',
  sharePositionOrigin: const Rect.fromLTWH(0, 0, 100, 100),
);

The rect values don’t need to be precise for iPhone since it uses modal presentation anyway. They just need to be non-zero. Rect.fromLTWH(0, 0, 100, 100) works fine.

For better UX on iPad, anchor the popover to the actual button that triggered the share:

final box = context.findRenderObject() as RenderBox?;
final sharePositionOrigin = box!.localToGlobal(Offset.zero) & box.size;

await Share.shareXFiles(
  files,
  sharePositionOrigin: sharePositionOrigin,
);

Alternative: Update share_plus

If you update to share_plus version 12.0.1 or later, the package handles this internally and won’t crash on iPhones even without the parameter. However, you should still provide sharePositionOrigin for proper iPad support—it has always been required there.

Complete Example

Before (crashes on iOS 26):

await Share.shareXFiles(
  files,
  subject: 'Export Data',
);

After (works on all iOS versions):

import 'dart:ui';

await Share.shareXFiles(
  files,
  subject: 'Export Data',
  sharePositionOrigin: const Rect.fromLTWH(0, 0, 100, 100),
);

Key Takeaways

1. Always provide sharePositionOrigin when using share_plus on iOS, even for iPhone-only apps

2. iOS 26 introduced stricter validation that breaks previously working code

3. Test on beta iOS versions when possible, especially before major releases

4. The fix is minimal—just add a non-zero Rect parameter

References

• GitHub Issue #3645: iOS 26 Unhandled Exception: PlatformException

• GitHub Issue #3685: SharePlus.instance.share fails in iOS 26

• share_plus package on pub.dev

This issue affected both HayTracker and PropaneTracker, two Flutter apps I built using Planning-Driven Development. The fix was a one-line change in each app.

Over the past year, I’ve built production applications in four languages and frameworks I had never used before: Go, React Native, Flutter/Dart, and Svelte. Not toy projects or tutorials—real applications deployed to app stores and production environments.

How? By leveraging GenAI agents not just as code generators, but as personalized tutors that teach through comparison to what I already know.

My Background: .NET and Vue.js Experience

I’ve spent decades in the .NET ecosystem—C#, F#, ASP.NET—and have solid experience with Vue.js for frontend development. When I decided to build PulseURL (a high-performance traffic monitoring service), DevHours (a time tracking app), HayTracker (hay inventory management), and an MFE shell example, I chose technologies completely outside my comfort zone:

• Go for PulseURL’s backend services

• React Native for DevHours mobile app

• Flutter/Dart for HayTracker and PropaneTracker

• Svelte for the micro-frontend shell

Each required learning a new language, new runtime, new ecosystem, and new idioms. The traditional path—tutorials, documentation, Stack Overflow—would have taken months. Instead, I was productive within days.

The Comparison-Driven Learning Method

The key insight is this: GenAI agents can teach you a new language by constantly comparing it to what you already know. This isn’t just faster—it’s deeper. You understand not just what to do, but why the language does it that way and how it relates to concepts you’ve already internalized.

Step 1: Start with Planning-Driven Development

Before writing any code, I follow my Planning-Driven Development approach. The first conversation with the GenAI agent isn’t about code—it’s about choices:

Me: "I need to build a high-throughput traffic monitoring service with gRPC ingestion.
I'm most familiar with .NET/C#, but I want to use this as an opportunity to learn
a new language. What are my options and the pros/cons of each?"

The agent responded with four options—Go, Node.js, Rust, and Python—each with detailed pros and cons considering:

• Runtime characteristics

• Concurrency models

• Ecosystem maturity

• Learning curve from my .NET background

• Deployment considerations

I asked follow-up questions about Go specifically, and we concluded it would be an excellent learning experience while being particularly well-suited to the problem: goroutines for high concurrency, excellent gRPC support, and a straightforward deployment story.

This isn’t about getting a “right” answer—it’s about understanding the tradeoffs before committing, while being intentional about learning.

Step 2: Establish Industry Standards

Once I choose a framework, the next question is crucial:

Me: "I've decided on Go for this project. What are the industry-standard
patterns and libraries for:
- Project structure
- HTTP routing
- Database access
- Configuration management
- Testing
- Error handling"

The response gives me the lay of the land. For Go, I learned about:

• The standard cmd/ and internal/ directory structure

• Popular routers like Chi and Gin

• The convention of _test.go files

• The Go error handling philosophy

This prevents me from accidentally adopting non-idiomatic patterns that would confuse experienced Go developers reviewing my code later.

Step 3: Teach Through Comparison

Here’s where the real learning happens. I tell the GenAI agent what I know:

Me: "I'm very familiar with C# and F#. As we work on this Go project,
please explain Go concepts by comparing them to their .NET equivalents.
Show me both the Go way and how I would have done it in C#."

For mobile/frontend work, I’d anchor to Vue.js instead:

Me: "I have experience with Vue.js. As we build this React Native app,
compare React patterns to Vue equivalents—components, state management,
lifecycle hooks, reactivity."

From this point forward, every explanation comes with a comparison:

Go’s goroutines vs. C#’s Tasks:

// Go: goroutine
go func() {
    result := fetchData()
    channel <- result
}()

// C#: Task
Task.Run(async () => {
    var result = await FetchDataAsync();
    // result available here
});

The agent explains: “Goroutines are lighter than Tasks—Go can run millions of them. But unlike async/await, you communicate through channels rather than awaiting results directly.”

This comparison-based teaching creates mental bridges. I’m not learning from scratch; I’m extending what I already know.

Step 4: Deep Dive on Syntax and Semantics

When I encounter unfamiliar constructs, I ask:

Me: "What are goroutines exactly? How do they compare to Task.Run and
async/await in C#? What about F#'s async workflows?"

The response covers:

• What goroutines are (lightweight threads managed by Go runtime)

• How channels differ from awaiting results

• The select statement for multiplexing

• When to use buffered vs. unbuffered channels

• Common pitfalls coming from an async/await background

For Dart, I asked similar questions:

Me: "What does 'final' mean in Dart? How is it different from 'const'?
Compare to TypeScript's const and readonly."

Me: "What is a Future in Dart? How does it compare to Promises in JavaScript?"

Each answer deepened my understanding by anchoring new concepts to familiar ones.

Step 5: Libraries and Ecosystem Navigation

Every language has its ecosystem. Rather than googling “best Go gRPC library,” I ask:

Me: "I need to build a gRPC service in Go. I've never used gRPC before.
What are the standard libraries and patterns? How does it compare to
building REST APIs, which I'm familiar with?"

The agent explains Go’s official gRPC library, protoc code generation, the request/response model, and how it differs from REST—all while teaching me both Go and gRPC simultaneously.

For Svelte, I asked about UI component libraries:

Me: "What UI component libraries are available for Svelte? I'm familiar with
Vuetify in Vue.js. What are the options and their pros/cons?"

After evaluating the options, we decided on shadcn-svelte. Then I learned that shadcn copies components into your codebase rather than installing as dependencies—a fundamentally different approach from Vuetify that makes sense once explained.

Step 6: Read Every Line of Generated Code

This is critical: never blindly accept generated code. I read every file, every function, every line. When something is unclear:

Me: "In this Go code, what does 'defer' do? I see it before the
db.Close() call. What's the equivalent in C#?"

Answer: “defer schedules a function to run when the surrounding function returns—like a finally block or IDisposable.Dispose(), but more flexible. In C# you’d use ‘using’ or try/finally.”

This questioning habit ensures I actually learn the language rather than just generating code I don’t understand.

Step 7: Discover Paradigm Differences

Sometimes, a new framework challenges your assumptions. When working with React Native, I noticed the code was constantly creating copies of objects rather than mutating them:

Me: "I notice React code keeps creating new object copies instead of mutating.
This looks like functional programming—immutability, pure functions. How does
this relate to patterns I know from F#?"

The agent explained React’s functional philosophy:

• Components as pure functions of props and state

• Hooks as composable state machines

• Immutable state updates (spread operators, new arrays) vs. Vue’s reactive mutations

• How this mirrors F#’s immutability-by-default approach

This wasn’t just syntax translation—it was understanding a different paradigm. Vue’s reactivity “just works” with direct assignment; React requires you to create new state objects. Once I recognized the F# connection, React’s patterns clicked.

Example Questions Across Projects

Here are examples of the kinds of comparison questions that accelerate learning in each stack:

PulseURL (Go)

Coming from C#, Go felt minimalist. Examples of what to ask:

• “Go doesn’t have exceptions. How do I handle errors compared to try/catch?”

• “What’s the equivalent of dependency injection in Go?”

• “How do interfaces work in Go vs. C#? I see no ‘implements’ keyword.”

Go’s implicit interface satisfaction is worth understanding early—types implement interfaces automatically if they have the right methods. Coming from C#’s explicit class Foo : IFoo, this feels strange until you understand the design philosophy.

DevHours (React Native)

React Native still uses TypeScript, so the language was familiar—but the React paradigm was new. Coming from Vue.js, examples of what to ask:

• “How does React’s useState compare to Vue’s ref() and reactive()?”

• “What’s the equivalent of Vue’s computed properties in React?”

• “How do React’s useEffect hooks compare to Vue’s watch and lifecycle hooks?”

• “Vue uses v-model for two-way binding. How does React handle form inputs?”

React’s explicit state management (useState, useReducer) vs. Vue’s reactivity system is the biggest mental shift. Understanding how React’s unidirectional data flow differs from Vue’s more magical reactivity is key.

HayTracker (Flutter/Dart)

Flutter/Dart was completely new, but comparing to JavaScript/TypeScript patterns from Vue.js still helps. Examples of what to ask:

• “How does Flutter’s StatefulWidget compare to a Vue component with reactive state?”

• “Dart has ‘final’ and ‘const’. How do these map to TypeScript’s const and readonly?”

• “What’s a Future and how does async/await work in Dart vs. JavaScript Promises?”

• “How does Flutter’s build() method compare to Vue’s template rendering?”

Flutter’s “everything is a widget” philosophy and the widget tree takes adjustment. But Dart itself feels comfortable—the syntax has familiar async/await patterns from both JavaScript and C#.

MFE Shell (Svelte)

Svelte’s reactivity model actually feels closer to Vue than React. Examples of what to ask:

• “How does Svelte 5’s $state and $derived runes compare to Vue’s ref() and computed()?”

• “Svelte compiles away the framework. How is this different from Vue’s virtual DOM?”

• “How do Svelte stores compare to Vue’s Pinia or Vuex?”

• “How do I use shadcn-svelte? In Vue I’d npm install Vuetify.”

Interestingly, Svelte’s approach to reactivity feels more natural coming from Vue than React did. The runes ($state, $derived) map conceptually to Vue’s ref() and computed().

The Compound Effect

After building four projects in four new stacks, something interesting happened: learning accelerated. Each new language became easier because:

1. Pattern recognition improves: “Oh, this is like goroutines in Go / Futures in Dart”

2. Paradigm awareness grows: Functional, OOP, and hybrid approaches become familiar

3. Ecosystem navigation becomes intuitive: Package managers, testing frameworks, and build tools follow patterns

4. Questions become more precise: I know what to ask about

Am I an Expert? No. Do I Need to Be? Also No.

I’ll be honest: I had never done mobile development before these projects. I’m not a Flutter/Dart expert. I don’t have years of production debugging experience, deep knowledge of the widget lifecycle internals, or muscle memory for every Flutter package. I’m not a React Native expert either.

But I understand:

• Each language’s philosophy and idioms

• How to read and understand Dart and React Native code

• Where to look when I encounter problems

• How to write idiomatic code rather than forcing familiar patterns where they don’t belong

And crucially: I have two apps in the iOS App Store and Google Play Store built with Flutter/Dart—HayTracker and PropaneTracker.

As I continue working with each language, depth builds naturally. Each bug I fix, each feature I add deepens understanding. The GenAI-accelerated learning got me to productive—and for these projects, productive is exactly what I needed.

The Method Summarized

1. Start with planning: Ask about language/framework choice with pros and cons

2. Establish standards: Learn industry-standard patterns before writing code

3. Declare your background: Tell the GenAI what you know so it can compare

4. Learn through comparison: Every new concept tied to a familiar one

5. Ask about everything: Syntax, semantics, runtime, libraries, idioms

6. Read every line: Don’t accept code you don’t understand

7. Question paradigm differences: Understand why the language works this way

Conclusion

GenAI agents have fundamentally changed how I approach learning new technologies. Instead of months of tutorials and documentation, I can become productive in days by leveraging comparison-based learning.

The key is treating the GenAI agent not as a code generator, but as a tutor who knows both what you’re learning and what you already know. Every explanation anchored to familiar concepts. Every new pattern compared to old ones. Every question answered with context.

The result: four production applications in four new stacks, built while actually understanding the code I was shipping.

For the foundation of this approach, see Planning-Driven Development: The Single Biggest Productivity Multiplier with GenAI Agents.

For examples of what’s possible with this approach, see DevHours, HayTracker, and PropaneTracker.

I have donkeys and goats. They eat hay. A lot of hay.

We order more hay when we’re down to the final bale, but I had no idea how long that last 4x5 round bale would actually last. Would it last two weeks? A month? I genuinely didn’t know. Having that information would help me plan ahead instead of just reacting.

Beyond timing, I wanted to track costs. How much am I actually spending on hay per year? We’re a small operation, but the expenses add up. I could put this in a spreadsheet, but an app on your phone makes it easy to log entries right there in the barn.

I wanted something simple: track deliveries, track usage, and build a history I could actually use for planning. HayTracker is that app.

Planning-Driven Development in Practice

This was my first Flutter app built entirely with Planning-Driven Development. Before writing any code, Claude Code and I created a comprehensive planning document—1,441 lines covering everything from database schema to UI specifications.

The planning phase addressed decisions that would otherwise interrupt development:

• How to model different bale types (small square, large round, etc.)

• The difference between hay tracking (sequential: stock → in use → consumed) and straw tracking (batch: stock → consumed)

• What consumption metrics to calculate and how to present depletion projections

• Pre-loaded bale type definitions based on industry standards

With the plan complete, implementation followed the roadmap. The first commit message tells the story: “Implement Phase 1 MVP of HayTracker.” Not “initial commit” or “WIP”—a complete, working foundation built to spec.

The result: ~8,900 lines of Dart across 60 files, with clean architecture, full CRUD operations, consumption analytics, and CSV export/import. HayTracker later served as the architectural template for PropaneTracker, demonstrating how a well-planned codebase becomes a reusable pattern.

What the App Does

HayTracker tracks two materials with distinct workflows:

Hay: Uses three-state tracking. Bales move from Stock (in the barn) → In Use (currently feeding from) → Consumed. This models how many people feed hay: you open up a bale and pull from it until it’s gone before starting the next one.

Straw: Uses simpler two-state tracking. Bales go directly from Stock → Consumed. Straw is typically used in batches for bedding—you spread several bales at once.

From this data, the app provides:

Consumption Projections: Based on your usage history, the app calculates bales per day and projects when you’ll run out. Urgency levels (critical: <7 days, warning: 7-30 days, ok: >30 days) give you visual feedback at a glance.

Delivery Tracking: Record deliveries with quantity, cost per bale, and delivery fees. Build a purchase history you can reference when comparing suppliers or budgeting.

Transaction History: Every inventory change is logged—bales used, adjustments made, deliveries received. Full audit trail of your hay operation.

Technical Highlights

Pre-loaded Bale Types

The app ships with nine standard bale sizes based on industry specifications:

• 2-string and 3-string small squares (hay and straw variants)

• 4x4, 4x5, and 5x5 round bales

• Large square bales

Users can customize dimensions and weights, or create entirely new bale types. This pre-seeding eliminates the “blank slate” problem where users have to configure everything before the app is useful.

Domain-Driven Architecture

HayTracker follows clean architecture with a clear separation between domain logic and storage. The domain layer defines what the data looks like and what operations are possible; the data layer handles how it’s persisted.

The domain model is a rich object with behavior:

class Inventory {
  final String id;
  final BaleType baleType;  // Full object, not just an ID
  final InventoryState state;
  final int count;
  final DateTime lastUpdated;

  double get totalWeight => baleType.typicalWeight * count;
}

The domain also defines repository interfaces—contracts that describe what operations are available:

abstract class InventoryRepository {
  Future<List<Inventory>> getInventoryByMaterial(MaterialType material);
  Future<void> updateInventory(Inventory inventory);
}

The data layer provides SQLite implementations that fulfill these contracts, handling the mapping between flat database rows and rich domain objects:

class InventoryRepositoryImpl implements InventoryRepository {
  Future<Inventory> _mapToDomain(Map<String, dynamic> map) async {
    // Resolve the foreign key to a full domain object
    final baleType = await _baleTypeRepository.getBaleTypeById(
      map['bale_type_id'] as String,
    );
    if (baleType == null) {
      throw Exception('BaleType not found: ${map['bale_type_id']}');
    }

    return Inventory(
      id: map['id'] as String,
      baleType: baleType,
      state: InventoryState.fromString(map['state'] as String),
      count: map['count'] as int,
      lastUpdated: DateTime.parse(map['last_updated'] as String),
    );
  }
}

Use cases orchestrate domain operations without touching storage details. Here’s UseBalesUseCase, which moves bales from stock to in-use:

Future<void> execute({
  required BaleType baleType,
  required int count,
  String? notes,
}) async {
  // 1. Validate stock
  final stockInventory = await _inventoryRepository.getInventory(
    baleTypeId: baleType.id,
    state: InventoryState.stock,
  );
  if (stockInventory == null || stockInventory.count < count) {
    throw Exception('Not enough bales in stock');
  }

  // 2. Reduce stock
  final updatedStock = stockInventory.copyWith(
    count: stockInventory.count - count,
    lastUpdated: DateTime.now(),
  );
  await _inventoryRepository.updateInventory(updatedStock);

  // 3. Update in-use inventory
  // ... (create or increment in-use count)

  // 4. Record transaction for audit trail
  await _transactionRepository.addTransaction(transaction);
}

The use case works entirely with repository interfaces and domain objects—no SQL, no database details. This makes it testable without any infrastructure and portable if the storage layer ever changes.

The Commit History

da7af8d Implement Phase 1 MVP of HayTracker
9913261 Add delivery entry form with inventory integration
30ac57e Add bale type management and deploy bales features
ce022cd Add consume bales feature and refactoring utilities
4516969 Add transaction/delivery history screens and inventory adjustment
2274eff Add CSV export/import functionality
526e35f Add consumption analytics and inventory projections

Each commit represents a complete feature, not incremental fumbling. The planning document served as both spec and checklist. When a phase was complete, it was complete—no circling back to fix architectural mistakes.

Simple, But Useful

HayTracker won’t manage your entire farm operation. It tracks one thing: how much hay and straw you have, and when you’ll need more. That’s it.

If you’ve ever run low on hay because you lost track, or if you want actual data when planning purchases, give it a try.

Download: iOS App Store | Google Play Store

Related: PropaneTracker - the propane tracking app built using HayTracker as a template

For the methodology behind this app, see Planning-Driven Development: The Single Biggest Productivity Multiplier with GenAI Agents.

This would not have happened without Claude Code.

I don’t mean it would have taken longer. I mean it would not have happened at all. The time investment would have been prohibitive. The mental calculus that every developer knows—”is this project worth the weeks of evenings it will take?”—would have killed all of these ideas before they started.

But something fundamental has changed. With Claude Code, days of work now take hours. Even a single spare hour can be genuinely productive, not just “getting back into flow” time. The barrier to starting has dropped so dramatically that projects I would have dismissed as impractical are now not only possible but shipped and running in production.

The Before and After Reality

Every developer has a graveyard of unbuilt projects. Ideas that seemed great until you calculated the real cost: weeks of evenings after work, weekends sacrificed, the slow grind of building everything from scratch. Most projects die in that calculation phase. The ones that survive often stall halfway through when life gets in the way and you lose momentum.

I’ve been a professional developer for over three decades. I have a good sense of how long things take. A mobile app with proper architecture, database layer, state management, and polished UI? That’s months of focused work. A multi-language reference implementation for Kubernetes debugging? That’s a substantial project requiring expertise in each language ecosystem. A traffic monitoring service with client libraries for multiple platforms? That’s an entire product.

Before Claude Code, I couldn’t realistically tackle even one side project per year. The economics simply didn’t work.

Now? The math is completely different. What used to take days takes hours. What used to take weeks takes days. And critically, I can make meaningful progress in sessions as short as an hour. That changes everything about what’s possible in spare time.

Seven Months of Building: The Projects

Here’s what I built from July 2025 through January 2026:

Developer Tools

env-run and env-run-pwsh solve the problem of managing multiple environment configurations (dev, uat, prod) with layered configuration and secure secret management. The Bash version came first, then I ported it to PowerShell for cross-platform support. These are small but genuinely useful tools that I use daily.

nginx-dev-gateway is a namespace-aware NGINX-based API gateway for Kubernetes that lets developers access multiple microservices through a single kubectl port-forward command. It supports path-based routing, WebSocket connections, and hot-reload configuration. I use this every day at my job—it has transformed my development workflow.

k8s-vscode-remote-debug is a comprehensive reference repository providing production-ready examples for remote debugging applications in Kubernetes from local VS Code. It supports eight languages: C#, F#, Node.js, Python, Go, Java, Rust, and Elixir. Each implementation includes Dockerfiles, Kubernetes manifests, VS Code launch configurations, and management scripts.

Traffic Monitoring (PulseURL Ecosystem)

PulseURL is a high-performance traffic monitoring service I built in Go with gRPC. It collects and aggregates HTTP request metrics with Redis for time-series storage.

pulseurl-dotnet provides a production-ready .NET client library and ASP.NET Core middleware with async buffering, exponential backoff retry logic, circuit breaker patterns, and batch streaming for 10x+ throughput improvement.

pulseurl-go is the Go client with Gin middleware, offering the same fire-and-forget design pattern with automatic retries and sampling support.

Building a complete observability product with clients for multiple platforms would traditionally be a significant undertaking. With Claude Code, I had the entire ecosystem working in under a month.

Mobile Apps

The mobile apps were the most satisfying to ship because they’re real products that real people use.

DevHours is a timer-based time tracking app for developers. It tracks time against projects and work items, categorizes by task type, generates reports, and exports to CSV. It was my first mobile app, built with React Native and Expo, following strict TDD practices with 148 tests.

HayTracker is a Flutter app for tracking hay and straw bale inventory, designed for farmers and livestock managers to monitor feed and bedding supplies. It features SQLite storage, CSV export, and Material Design 3 UI.

PropaneTracker is a Flutter app for tracking propane tank usage, deliveries, and consumption. Like HayTracker, it’s built on SQLite with comprehensive data management features.

All three apps are available on the iOS App Store. PropaneTracker and HayTracker are also live on Google Play, with DevHours Android coming in 2026.

Web and MFE Projects

rapid-ui-prototype demonstrates a GenAI-powered rapid prototyping system with side-by-side prototype/production architecture. It includes eight pre-configured scenarios (Normal, Empty, Large Dataset, Error States, etc.) and seamless migration paths from prototype to production code.

mfe-svelte-shell is a reference implementation of micro-frontend architecture with a lightweight Svelte 5 shell orchestrating MFEs built in React, Vue, SolidJS, and Angular. It demonstrates static manifest registration, cross-MFE communication, and mock authentication patterns. I used this as the blueprint for building a production MFE system at my job, as described in From MFE Blueprint to Development Platform.

dev.nathanfox.net serves as a central hub for documentation, legal pages, and scripts.

www.codepasture.com is the marketing website for my new company, built with SvelteKit.

The Numbers: What Would This Have Taken?

How long does it take to write production code? Industry benchmarks vary, but studies consistently show experienced developers produce 50-80 lines of tested, production-ready code per day on average. The classic “Mythical Man-Month” cites even lower figures for large projects. Solo developers with no meetings or bureaucracy trend toward the higher end. Here’s how long each project would take using both benchmarks:

The “Actual Timeline” column shows when each project was built—the calendar span from first commit to completion. But how many hours did I actually invest?

Working 10-15 hours per week over 7 months:

• 7 months × 4.3 weeks × ~12.5 hours/week = ~375 hours

• 67,767 lines ÷ 375 hours = ~180 lines per hour

That’s roughly 1,440 lines per 8-hour equivalent day—18-29x the traditional benchmarks. The numbers sound implausible until you try it yourself. But the git commits are there, the apps are in the app stores, the projects are real and working.

The documentation column is worth noting: 34,000 lines of markdown documentation that also wouldn’t exist without Claude Code. This includes comprehensive READMEs, API documentation, setup guides, and architecture explanations. In traditional development, documentation is often the first thing cut when time gets tight.

But here’s the key insight that the numbers don’t capture: without the productivity multiplier, I wouldn’t have attempted any of these projects at all. The multiplier isn’t just about doing things faster—it’s about crossing the threshold where projects become worth starting. When you can make real progress in a single evening, the calculus changes completely.

The Technology Diversity

One of the most striking aspects of this period is the breadth of technologies I worked with productively:

In traditional development, switching between technology stacks carries significant context-switching costs. Each ecosystem has its idioms, best practices, tooling, and gotchas. Learning them all at a professional level would take years.

With Claude Code, I can work effectively in technologies I don’t use daily. The agent knows the idioms. It knows the gotchas. It generates code that follows best practices for each ecosystem. I still need to understand what’s being generated and make architectural decisions, but the implementation friction is dramatically reduced.

This has profound implications for what individual developers can accomplish. You’re no longer limited to your primary tech stack.

The Business That Resulted: Code Pasture LLC

The volume and quality of output reached a point where forming a business made sense. In late 2025, I founded Code Pasture LLC.

The company has three mobile apps shipped to the iOS App Store, with HayTracker and PropaneTracker also on Google Play:

• DevHours: Time tracking for developers

• HayTracker: Inventory management for farmers

• PropaneTracker: Propane tank monitoring

Two more mobile apps are in active development and planned for release in 2026.

Beyond products, Code Pasture offers services for companies looking to adopt modern architectures:

• Mobile app development (Flutter/React Native)

• Micro-frontend shell development

• MFE development across frameworks

• Microservices architecture and implementation

None of this would exist if building software still took as long as it used to. I wouldn’t have had enough shipped products to justify a company. I wouldn’t have had the breadth of expertise across technologies to offer meaningful services. The business itself is a direct consequence of GenAI-enabled productivity.

Professional Impact: Beyond Side Projects

The benefits extend beyond personal projects. In my day job over the past four months, I’ve accomplished work that would have taken over a year using traditional development approaches.

There’s a compound effect at play: the skills I developed building personal projects—particularly around effective prompting, planning-driven development, and example-driven development—transferred directly to professional work. Each project made me better at working with GenAI agents, which made the next project faster, which built more skills.

This isn’t just about me. Teams that master these tools now will have a significant advantage over those that don’t. The gap between developers who leverage GenAI effectively and those who don’t is already substantial and growing.

What Made This Possible

Raw productivity gains aren’t automatic. Several practices made the difference:

Planning-Driven Development

I don’t start coding immediately. I start with a structured planning document that Claude Code helps create and then uses as context during implementation. This approach is detailed in Planning-Driven Development with GenAI Agents.

Planning first eliminates the “build it wrong then fix it” cycle that wastes so much time in traditional development. The agent understands the goals, constraints, and architecture before writing any code.

Example-Driven Development

Once you’ve figured out a working pattern—whether it’s Kubernetes debugging configuration, a micro-frontend shell setup, or a specific testing approach—capture it in a reference repository. Then point Claude Code at that example when implementing similar patterns in new projects.

This approach, detailed in Example-Driven Development: Using Working Code Examples to Guide AI Agents, has been transformative. Instead of rediscovering solutions through trial and error, I can say “follow the pattern in this repo” and get consistent, working implementations. The k8s-vscode-remote-debug and mfe-svelte-shell projects both started as examples that I’ve reused across multiple projects.

CLAUDE.md Configuration

Each project has a CLAUDE.md file that configures Claude Code with project-specific context, coding standards, and common gotchas. This eliminates the need to repeatedly explain the same things and ensures consistency across sessions.

Tool Stack

I use Claude Code as the primary coding agent, with GitHub Copilot for inline completions. The combination provides both autonomous implementation capability and seamless in-editor assistance.

Conclusion

Let me return to the thesis: these projects would not exist without GenAI agents.

Not “would have taken longer.” Would not exist.

I’ve been coding for over thirty years. I know what I could accomplish in spare time before this technology existed. The three mobile apps, the traffic monitoring ecosystem, the multi-language Kubernetes debugging reference, the MFE shell—none of these would have made it past the idea stage. The time investment would have been too high, the opportunity cost too great.

What we’re witnessing is a democratization of software development capability. Individual developers can now accomplish what previously required teams. Side projects can become real products. Ideas can become businesses.

The compound effect is just beginning. As I get better at working with these tools, as the tools themselves improve, as inference speeds increase—the multiplier will only grow.

I have two more mobile apps in development. More tools. More services to offer through Code Pasture. The project graveyard of unbuilt ideas is emptying out.

What projects have you been putting off because the time investment seemed too high? The math may have changed more than you realize.

Download the Apps

DevHours - Time tracking for developers

Android coming Q1 2026

HayTracker - Inventory management for farmers

PropaneTracker - Propane tank monitoring

Related posts:

• Achieving 4x+ Productivity Gains with GenAI Coding Agents

• Planning-Driven Development with GenAI Agents

• Example-Driven Development: Using Working Code Examples to Guide AI Agents

• DevHours: A Time Tracking App Built for Developers

• PropaneTracker: Propane Tank Monitoring

Something strange happened during our recent hiring round. We received a flood of applications—more than usual—and noticed a peculiar pattern. Many resumes hit all the right keywords, demonstrated broad technical knowledge, and read impressively well. Too well.

Then came the interviews.

In three separate interviews, we uncovered candidates clearly using GenAI assistance without disclosure. The tell? They knew what Reservoir Sampling was.

Let me explain. I have an old interview question: select a random line from a text file for a “quote of the day” feature. Simple enough. Then comes the constraint—you can only read through the file once, and you don’t know the total line count ahead of time.

This question isn’t about getting the right answer. In my entire career, exactly one person solved it correctly: a Ph.D. who had written a book on Lambda Calculus. The question exists to watch candidates think. How do they approach an unfamiliar problem? Do they ask clarifying questions? Can they reason through edge cases? Do they recognize when they’re stuck and pivot?

But suddenly, multiple candidates were confidently explaining Reservoir Sampling—the textbook-perfect algorithm that solves this exact problem. Not fumbling toward it. Not discovering it through reasoning. Just... knowing it. With the kind of precision that comes from asking an AI moments before answering—which, in these cases, they were doing in real time.

This isn’t about judging people for using AI. It’s about a fundamental mismatch: our interview processes were designed to test knowledge that GenAI now commoditizes.

The Knowledge Testing Paradox

Traditional technical interviews test things like:

• Can you explain how a hash map works?

• What’s the time complexity of this algorithm?

• How does garbage collection work in language X?

• Write a function to reverse a linked list

Here’s the uncomfortable truth: GenAI can answer all of these better than most humans. Not just adequately—better. With more precision, more edge cases covered, and more nuance than even experienced developers typically provide off the cuff.

So what are we actually testing? The ability to memorize information that’s instantly accessible to anyone with a GenAI tool?

This feels similar to testing someone’s arithmetic skills when they’ll always have a calculator on the job. Yes, understanding the fundamentals matters. But is rote recall the skill that will determine their effectiveness in a modern development environment?

The same question applies to pair coding sessions. We sit candidates down, share a screen, and watch them write code in real-time. It’s supposed to reveal how they think, how they collaborate, how they approach problems. But in practice? They’ll never code this way on the job. They’ll have an AI agent in their IDE, suggesting completions, generating functions, catching errors before they happen.

Are we testing a skill they’ll actually use, or are we testing their ability to perform without the tools they’ll have every single day?

A Different Approach: The Live AI-Assisted Build

What if instead of testing what candidates know, we tested how effectively they work with GenAI?

Here’s a format I’m considering:

The Setup

• 90 minutes, live session with screen sharing

• Candidate uses their preferred GenAI tools (Claude, ChatGPT, Copilot, etc.)

• They’re given requirements for a small but complete application

• The goal: get something working that meets the requirements

What We’d Observe

Planning Behavior

• Do they immediately start prompting for code?

• Do they first discuss requirements and architecture with the AI?

• Do they create any form of plan before implementation?

• How do they handle ambiguous requirements?

Prompting Effectiveness

• How specific are their prompts?

• Do they provide context effectively?

• How do they handle AI mistakes or misunderstandings?

• Do they iterate effectively when output isn’t right?

Technical Judgment

• Can they evaluate if AI-generated code is good?

• Do they catch bugs or security issues?

• Do they understand the code well enough to modify it?

• Can they explain what the code does and why?

Problem-Solving Approach

• How do they break down the problem?

• Do they test as they go or all at the end?

• How do they handle unexpected issues?

• What’s their debugging process when AI suggestions don’t work?

The Challenges

This approach isn’t without significant problems:

The Fairness Question

Different candidates have different levels of GenAI experience. Someone who’s been using Claude Code daily for six months will naturally outperform someone using ChatGPT for the first time. Is that fair?

Then again, is it fair to test algorithm implementation when some candidates grind LeetCode for months while others don’t?

The Evaluation Criteria

What actually makes someone “good” at AI-assisted development? We’d need to define rubrics for:

• Planning quality

• Prompting effectiveness

• Code comprehension

• Technical judgment

• Problem decomposition

These are harder to evaluate than “did the algorithm pass the test cases.”

The Time Factor

Can someone actually build something meaningful in 90 minutes, even with AI assistance? The scope would need to be carefully calibrated—complex enough to reveal problem-solving skills, simple enough to be achievable.

The Reproducibility Problem

Unlike algorithm questions with clear correct/incorrect answers, evaluating AI-assisted development is inherently subjective. Two evaluators might assess the same session differently.

What This Interview Might Reveal

Despite the challenges, I think this format could uncover things traditional interviews miss:

Adaptability: How quickly do they adjust when their first approach doesn’t work?

Communication: Can they effectively communicate with both AI and humans about technical concepts?

Quality Sense: Do they accept the first thing the AI generates, or do they critically evaluate output?

Systematic Thinking: Do they approach problems methodically or chaotically?

Learning Speed: How quickly do they pick up on what works and what doesn’t with AI assistance?

These feel like the skills that will actually matter for the next decade of software development.

The Uncomfortable Questions

I keep coming back to some fundamental tensions:

Are we hiring for today or tomorrow? Someone who’s excellent at traditional coding but mediocre at AI collaboration might be less valuable than the reverse in 2-3 years.

What is “real” skill now? If AI handles most code generation, is deep algorithmic knowledge a prerequisite or a nice-to-have? Is “prompt engineering” a real skill or a temporary artifact?

How do we value human judgment? Perhaps the most important skill is knowing when to trust AI output and when to be skeptical. How do you test that in 90 minutes?

What about fundamentals? There’s an argument that you need to understand code deeply to evaluate AI-generated code effectively. Should we still test fundamentals separately?

Where I’m Landing (For Now)

I don’t have answers, but I have a direction I want to explore:

A two-part interview:

1. Traditional Technical Discussion (60 min): Not algorithm coding, but a conversation about past projects, technical decisions, tradeoffs they’ve navigated. This reveals depth of experience that AI can’t fake in real-time conversation.

2. Live AI-Assisted Build (60-90 min): The format described above. See how they actually work, not just what they know.

The combination might give us:

• Evidence of genuine experience (hard to fake in real-time discussion)

• Insight into how they’ll actually work day-to-day

• Assessment of both foundational knowledge and modern tooling skills

An Open Question

I’m genuinely uncertain about this. The traditional interview is broken for the AI era, but we don’t yet know what the replacement looks like.

What I do know:

• Testing pure knowledge recall is increasingly meaningless

• How someone works with AI tools is increasingly relevant

• The best developers will use AI as a multiplier, not a replacement for thinking

• The worst AI-assisted code comes from people who don’t understand what they’re generating

The interview process needs to evolve. I’m not sure this is the right evolution, but it feels closer to testing what actually matters.

The Problem: A 500-Gallon Mystery

I heat my home with a 500-gallon propane tank. My tank has a transmitter that sends data to the propane company, so deliveries happen automatically—I never have to call. But that data flows one direction. The propane company knows my consumption patterns. I don’t.

For years, my “tracking system” was opening the Notes app on my phone and typing something like:

Jan 15 - 45%
Jan 22 - 38%
Feb 1 - delivery
Feb 3 - 82%

This was barely useful. I couldn’t easily see consumption trends, couldn’t analyze seasonal patterns, and had no way to plan ahead. Every year when it’s time to decide how much propane to prebuy for the next heating season, I was guessing.

I wanted something simple: track deliveries, track tank readings, and build a history of my actual consumption. PropaneTracker is that app.

Planning-Driven Development Meets Example-Driven Development

This project combined two approaches I’ve written about before:

Planning-Driven Development: Before writing any code, I created a comprehensive planning document with Claude Code. We worked through the domain model, architecture decisions, and implementation phases. The 1,066-line planning document covers everything from database schema to consumption calculation algorithms. (For more on this approach, see Planning-Driven Development: The Single Biggest Productivity Multiplier with GenAI Agents.)

Example-Driven Development: I pointed Claude Code at HayTracker, a Flutter app I’d built previously, and said “follow these patterns.” The architecture, file structure, testing approach, and Riverpod patterns were already proven. PropaneTracker just needed different domain models and UI.

The planning document took roughly an hour or two of back-and-forth with Claude Code. Then, with the plan in hand and HayTracker as an example, the core of the mobile app was generated in 90 minutes—about 6,300 lines of Dart across 51 files, roughly half the final codebase. But it was a working half: the architecture, persistence, state management, and basic UI were complete. Later commits added polish and features like CSV export and consumption statistics.

An hour and a half from planning document to working Flutter app with:

• Clean Architecture (domain/data/presentation layers)

• SQLite persistence

• Full CRUD for readings and deliveries

• Riverpod state management

• Unit tests for domain logic

This is the power of Claude Code with Opus 4.5 when you give it clear plans and good examples to follow.

What the App Does

PropaneTracker is deliberately simple. It tracks two things:

Tank Readings: Check your gauge, enter the percentage. The app records when you took the reading (with the option to backdate) and optionally the temperature.

Deliveries: Record gallons delivered, total cost, and optionally the tank percentage before and after the fill. The app calculates price per gallon automatically.

From this data, the app provides:

Consumption Statistics: How many gallons per day you’re using, broken down by month and year. Over time, this reveals seasonal patterns.

Time to 20% Estimate: Based on your recent consumption rate and current tank level, the app estimates when you’ll hit 20% capacity.

Delivery History: Total gallons purchased, total cost, average price per gallon over the last 12 months.

Technical Highlights

A few aspects of the implementation worth noting:

Unified Timeline with Dual Metrics

The most interesting technical challenge was consumption calculation. You have two data sources:

• Gauge readings: Frequent but approximate (±5% accuracy)

• Delivery records: Exact but infrequent

The ConsumptionCalculatorService merges both into a unified timeline and calculates two complementary metrics:

1. Percentage per day (from gauge readings) - good for short-term monitoring

2. Gallons per day (from deliveries) - precise, good for cost projection

When a delivery includes both percentageBefore and percentageAfter, the service can do normalized calculations that account for different fill levels between deliveries.

Clean Architecture

The project follows three-layer clean architecture:

lib/
├── domain/       # Pure Dart: models, repositories (interfaces), use cases, services
├── data/         # SQLite implementation of repositories
└── presentation/ # Flutter UI, Riverpod providers, screens, widgets

The domain layer has zero Flutter dependencies. Use cases are single-responsibility classes. This makes the business logic trivially testable.

Testable by Design

No DateTime.now() calls in services. Every method takes explicit date parameters:

Future<CurrentLevelEstimate> getCurrentLevelEstimate({
  required DateTime asOf,
  required DateTime rateStart,
  required DateTime rateEnd,
})

This means tests use deterministic dates and produce deterministic results. The test suite includes 18 test files covering models, use cases, services, repositories, and widgets.

Dual Timestamps on Readings

A small UX detail that makes a big difference: each reading has both readingDateTime (when you checked the gauge) and entryDateTime (when you entered it in the app). This supports the common case of checking the tank in the morning but entering the data later.

The Commit History Tells the Story

d1fea61 Add initial planning document for Propane Tracker app
1a11512 Phase 1: Flutter project setup and domain layer foundation
1fe6bf4 Phase 2: Repository implementations and use cases
158c14b Phase 3: Riverpod state management
95056e7 Phase 4: Presentation layer (UI)

Five commits took the project from planning document to working app. The subsequent commits added polish: custom icons, CSV export/import, consumption statistics UI, App Store compliance.

The methodical, phase-based approach meant each step built cleanly on the previous one. No major refactoring. No architectural pivots. The plan worked.

Simple, But Useful

PropaneTracker isn’t trying to be clever. It’s a digital replacement for my Notes app with just enough structure to be useful. Track what goes in (deliveries), track what’s left (readings), and build a consumption history you can actually use—whether that’s for prebuy decisions, budgeting, or just understanding where your heating dollars go.

If you heat with propane and want your own data, give it a try.

Download: iOS App Store | Google Play Store

Related: HayTracker - the Flutter app that served as the architectural template

For the methodology behind rapid app development with AI, see Planning-Driven Development: The Single Biggest Productivity Multiplier with GenAI Agents.

This is Part 3 of the JSNTM series. Part 1 made the pledge to stop creating monoliths. Part 2 presented a reference implementation for micro-frontends. This post covers what happened when I applied those patterns at work.

The Timeline

Days 1-2: MFE Shell with authentication, authorization, and full CI/CD deployed to the development Kubernetes cluster.

Days 3-5: First MFE with basic functionality, integrated with its API and deployed alongside the shell.

Five days from concept to working code on the development platform. Not a proof of concept—real infrastructure with real authentication hitting real APIs.

This is what happens when GenAI-assisted development meets Example-Driven Development.

The Setup

The existing system runs on Kubernetes with an API gateway handling path-based routing. Multiple services serve different bounded contexts, each accessible via /api/service-name/.

The frontend, however, is a single Vue application. Every feature, every team, one monolithic SPA. Classic frontend monolith hiding behind backend services.

Time to apply the JSNTM pledge to the UI layer.

Days 1-2: The Shell

The MFE Shell needed to:

• Integrate with existing Azure AD authentication (already used by the Vue app)

• Provide navigation, theming, and shared utilities

• Load MFEs dynamically based on a manifest

• Deploy to the same Kubernetes cluster via existing CI/CD patterns

• Work alongside the existing Vue application (gradual migration, not replacement)

I used Planning-Driven Development to create the planning documents first—a 25-page planning document and an 8-page implementation plan. The reference implementation served as the example—my GenAI agent analyzed its patterns and adapted them for the production environment.

The planning document captured the specifics:

• The existing app uses MSAL for Azure AD—integrate with the same auth library

• Follow the existing Helm chart patterns for Kubernetes deployment

• Configure API gateway mappings for /mfe/ routes

With the plan in place, implementation was methodical. Each phase had clear deliverables. By end of day 2, the shell was deployed and accessible, showing a working sidebar and authentication flow.

The First Lesson: Path Conflicts

Our API gateway routes requests based on path prefixes. We needed:

• /mfe/ - The shell application

• /mfes/ - Individual MFE bundles

That single character difference (/mfe/ vs /mfes/) matters.

Initially, both the shell SPA routes and MFE bundles lived under /mfe/. The gateway couldn’t distinguish between a shell page request (/mfe/feature-x) and an MFE bundle request (/mfe/feature-x/remoteEntry.js). Moving MFE bundles to /mfes/ gave each concern its own routing prefix.

The shell serves its SPA from /mfe/. MFE bundles load from /mfes/{mfe-name}/remoteEntry.js. Two distinct routing concerns, two distinct paths.

Days 3-5: The First MFE

With the shell deployed, the next step was proving the architecture with a real MFE. A new feature needed a UI for file uploads, processing status, and search functionality—a perfect candidate for a self-contained module.

The MFE needed to:

• Implement the lifecycle contract (bootstrap, mount, unmount)

• Communicate with its own API endpoints

• Register navigation routes with the shell

• Deploy independently from the shell

Here’s where it got interesting.

The Revelation: MFE Inside the Microservice

The conventional approach: create a separate repository for the MFE. Separate CI/CD. Separate versioning.

Instead, we put the MFE directory inside the microservice’s API repository:

microservice-api/
├── src/
│   └── api/           # API source code
├── tests/
├── mfe/               # MFE lives here
│   ├── src/
│   ├── Dockerfile
│   └── package.json
├── helm/
│   ├── api/           # API Helm chart
│   └── mfe/           # MFE Helm chart
└── azure-pipelines.yml

One repository. One CI/CD pipeline. One team.

When the API changes, the MFE updates in the same commit. When the MFE ships, the API ships with it. Version compatibility is guaranteed by colocation.

This is true vertical slicing—from database to API to UI, all owned by the same bounded context.

Why This Works So Well

Single Source of Truth: API types and MFE types stay synchronized. When an API response changes, the MFE types update in the same PR.

Simplified Code Review: Reviewers see the full feature—API changes and UI changes together. No cross-repository coordination.

Unified CI/CD: One pipeline builds both artifacts. The API container and MFE container deploy as a unit when appropriate, or independently when needed.

GenAI Context: Your coding agent sees both the API and MFE in the same workspace. “Add a new field to this API response and display it in the UI” becomes a single conversation, not coordination across repositories.

Team Ownership: The team owns the bounded context completely. No handoffs between “backend team” and “frontend team” for feature development.

The Authentication Story

The existing Vue application already used MSAL for Azure AD authentication. Users were already logged in. How does the shell access that authentication state?

The answer: shared token cache.

MSAL stores tokens in localStorage by default. The Vue app and the MFE Shell run on the same domain. Same domain means same localStorage. Same localStorage means the shell can access tokens the Vue app already acquired.

No duplicate login prompts. The user logs into the Vue app once, navigates to an MFE route, and they’re already authenticated. The shell’s auth store initializes from the shared cache.

This works because:

• Same domain (no cross-origin issues)

• Same Azure AD tenant and client configuration

• Same MSAL library storing tokens with the same cache keys

For greenfield deployments, the shell would handle initial authentication. In migration scenarios like this, the shared cache provides seamless SSO.

Static Deployment with Nginx

Both the shell and MFEs deploy as static files served by Nginx containers. No Node.js runtime in production. No server-side rendering.

The Dockerfile follows a multi-stage pattern:

1. Node.js build stage: npm run build

2. Nginx production stage: Copy built files, apply nginx.conf

The nginx configuration handles:

• SPA routing (all paths serve index.html)

• Aggressive caching for hashed assets (1 year, immutable)

• No caching for entry points (index.html, remoteEntry.js)

• Security headers

• Gzip compression

The Manifest

MFEs register via a JSON manifest that the shell loads at startup:

{
  "mfes": [
    {
      "id": "feature-x",
      "name": "Feature X",
      "entry": "/mfes/feature-x/remoteEntry.js",
      "route": "/feature-x",
      "requiredRoles": ["RoleA", "RoleB"],
      "menu": {
        "label": "Feature X",
        "icon": "FileText",
        "order": 1
      }
    }
  ]
}

Adding a new MFE means adding an entry to the manifest and deploying the bundle. The shell discovers and loads it automatically.

Role-based filtering happens client-side. If the user lacks required roles, the menu item doesn’t appear. This complements API-level authorization—the backend still validates permissions on every request.

Lessons for Others

Separate shell and MFE paths. /mfe/ for the shell, /mfes/ for bundles. Avoid routing conflicts in your API gateway.

Colocate MFEs with their APIs. Put the MFE inside the microservice repository. Vertical slices simplify everything.

Leverage existing auth infrastructure. If you have working authentication, share the token cache. Don’t duplicate login flows.

Static deployment is enough. Nginx serving built files is simple, fast, and sufficient for SPAs and MFEs.

Start with one MFE. Prove the architecture with a single module before migrating existing features.

What’s Next

The shell is deployed. The first MFE is live on the development platform. The pattern is proven.

Future MFEs follow the same template. Clone the MFE directory structure, implement the lifecycle contract, add a manifest entry. GenAI accelerates each iteration using the first MFE as the example.

The existing Vue monolith doesn’t need to migrate all at once. New features can be MFEs from day one. Existing features can migrate as capacity allows. The shell and Vue app coexist, sharing authentication and routing.

This is incremental architecture improvement—enabled by GenAI development speed and Example-Driven Development.

The JSNTM Pledge Continues

Part 1: No more monolithic backend services. Part 2: A reference implementation for the frontend. Part 3: Validation on the development platform in 5 days.

The patterns work. The timeline is real. The only barrier is starting.

This post is part of the JSNTM series on eliminating monoliths with GenAI-assisted development. See Part 1 for the original pledge and Part 2 for the reference implementation.

This post was written with a GenAI coding agent. I described the experience and the agent helped identify patterns and structure the content. I reviewed and edited the result. This is how I work now. You can see the revision history in my blog posts repo.

When I first started using GenAI coding agents, I did what everyone does: I wrote prompts to construct code. “Create a domain model for user management.” “Build a REST endpoint for user authentication.” “Add a repository class with Dapper.”

It worked. Sort of. The code came out, but then came the endless cycle: editing, refactoring, re-prompting, fixing edge cases, realigning with requirements. Every correction required another conversation. Every misunderstanding meant more rework.

Then I discovered something that fundamentally changed my productivity: planning documents are infinitely easier to edit than code.

In a recent project, I spent roughly 6 hours generating a 10-page planning document and a 48-page implementation plan with my GenAI agent. Yes, that’s a lot of reading. But the development that followed? It went so smoothly that the output was 90-95% of what was expected on the first pass. And this wasn’t a one-off—I’m seeing this level of success repeatedly across different projects and problem domains.

This post expands on my previous article about Planning-First Development, diving deeper into the specific patterns and document structures that make this approach so effective. I call it “Planning-Driven” here because the plan isn’t just something you do first—it’s what drives the entire development process, guiding every session and decision along the way.

Why Planning Documents Beat Prompt Engineering

The Economics of Editing

Consider the cost of changing direction at different stages:

StageCost to Change DirectionPlanning DocumentMinutes (edit text)Prompt RefinementHours (regenerate, review, test)Code EditingHours to Days (refactor, test, debug)Post-DeploymentDays to Weeks (hotfix, rollback, user impact)

When you’re working with a GenAI agent, every code change requires:

1. Understanding existing context

2. Formulating the right prompt

3. Reviewing generated code

4. Testing for regressions

5. Integrating with existing code

When you’re refining a planning document, you:

1. Edit text

2. Done

Plans as Shared Context

A well-structured planning document becomes the shared understanding between you and the GenAI agent. When you start each development session with “Follow the plan in IMPLEMENTATION_PLAN.md, we’re working on Phase 3,” the agent has:

• Complete project context

• Architectural decisions already made

• Clear deliverables for the current phase

• Testing strategy defined

• Integration points documented

No need to re-explain. No context drift. No misunderstandings about what “done” looks like.

The Two-Document Pattern

Through experimentation across multiple projects, I’ve settled on a two-document approach:

Document 1: The Planning Document (Business-Facing)

This is the high-level document you can share with stakeholders, business users, and team members. It answers:

• What are we building?

• Why are we building it?

• What are the requirements?

• What does success look like?

This document is typically 5-15 pages and uses language that non-technical stakeholders can understand.

Document 2: The Implementation Plan (Developer-Facing)

This is the detailed technical roadmap. It answers:

• How will we build it?

• What is the architecture?

• What are the phases and tasks?

• What are the file structures?

• What code patterns will we use?

This document can be substantial—40-60 pages for complex projects—but it’s worth every line.

Anatomy of an Effective Planning Document

Based on patterns I’ve observed across dozens of planning documents, here’s the structure that works:

1. Executive Overview

# Project Name Planning Document

## Overview
Brief description of what we're building and why.

## Background
Current state, problems being solved, reason for change.

## Goals
- Primary goal 1
- Primary goal 2
- Success criteria

The overview should be understandable by anyone in the organization. No jargon, no implementation details.

2. Requirements Section

## Requirements

### Core Requirements
1. **Requirement Name**: Description of what must be accomplished
   - Acceptance criteria
   - Edge cases to consider

### Business Rules
1. **Rule Name**: Business logic that must be enforced

Be specific. Vague requirements lead to vague implementations. If a business user can misinterpret a requirement, they will—and so will your GenAI agent.

3. Proposed Architecture (High-Level)

Example Components Table:

ComponentDescriptionAPI LayerHandles HTTP requests, validationDomain LayerBusiness logic, rules enforcementData LayerDatabase operations, caching

Example Key Decisions Table:

DecisionChoiceRationaleDatabaseSQL ServerEnterprise support, team expertiseFrameworkASP.NET CoreC# ecosystem, performance, tooling

Decision tables are crucial. They capture not just what you chose, but why. This prevents re-litigating decisions later and gives the GenAI agent context for making consistent choices.

4. Implementation Phases

## Implementation Phases

### Phase 1: Foundation
- Set up project structure
- Define domain model (entities, enums, value objects)
- Implement domain services and business rules
- Write unit tests for domain logic

### Phase 2: Infrastructure
- Create database schema and migrations
- Implement repositories with Dapper
- Write repository integration tests

### Phase 3: API Layer
- Create API endpoints
- Add request validation
- Integration testing

### Phase 4: Polish
- Error handling
- Logging and observability
- Documentation
- Performance optimization

Phases provide natural checkpoints for review and create clear scopes for development sessions with the GenAI agent.

Anatomy of an Implementation Plan

The implementation plan is where the magic happens. This is the document you and your GenAI agent work from directly.

1. Document Metadata

Track status so you always know where you left off:

FieldValueCreated2024-01-15StatusIn ProgressCurrent PhasePhase 2

2. Domain Model First

My implementation plans always start with the domain model. This aligns with my Domain-First Development approach—build your domain types and business logic before thinking about databases, APIs, or UI.

## Domain Model

### Core Entities

Define your domain types with their properties and relationships:

public record User
{
    public Guid Id { get; init; }
    public string Email { get; init; } = string.Empty;
    public string Name { get; init; } = string.Empty;
    public UserRole Role { get; init; }
    public DateTime CreatedAt { get; init; }
    public DateTime? LastLogin { get; init; }
}

public enum UserRole
{
    Admin,
    Member,
    Viewer
}

### Domain Rules

Document the business rules that govern your domain:

1. **Email Uniqueness**: No two users can share the same email address
2. **Role Transitions**: Only Admins can promote users to Admin role
3. **Soft Delete**: Users are never hard-deleted; they are deactivated

Starting with the domain model ensures you and the GenAI agent have a shared understanding of the business concepts before any infrastructure code is written.

3. Technical Decisions

Example Technical Decisions Table:

DecisionChoiceRationaleData AccessRepository PatternTestability, abstractionAPI StyleRESTful + OpenAPIIndustry standard, toolingError HandlingResult typesExplicit, composableTestingTDD with xUnitFast feedback, documentation

4. Project Structure

MyProject/
├── src/
│   ├── MyProject.Domain/           # Pure domain model (no dependencies)
│   │   ├── Entities/
│   │   │   └── User.cs
│   │   ├── Services/
│   │   │   └── UserService.cs
│   │   └── Validation/
│   │       └── UserValidator.cs
│   ├── MyProject.Api/              # HTTP endpoints
│   │   ├── Controllers/
│   │   │   └── UsersController.cs
│   │   └── Program.cs
│   └── MyProject.Infrastructure/   # Data access, external services
│       ├── Repositories/
│       │   └── UserRepository.cs
│       └── External/
│           └── EmailService.cs
├── tests/
│   ├── MyProject.Domain.Tests/
│   └── MyProject.Api.Tests/
└── docs/
    ├── PLANNING.md
    └── IMPLEMENTATION_PLAN.md

ASCII directory trees are surprisingly effective for GenAI agents. They understand the structure immediately and maintain consistency when creating new files.

5. Domain Logic Examples

Include actual code in your implementation plan. The GenAI agent will use these as templates and maintain consistency throughout the codebase.

// Domain service pattern - pure business logic
public class UserService
{
    public Result<User> CreateUser(CreateUserCommand command)
    {
        var validationResult = ValidateCreateCommand(command);
        if (!validationResult.IsSuccess)
            return Result<User>.Failure(validationResult.Errors);

        var user = new User
        {
            Id = Guid.NewGuid(),
            Email = command.Email.ToLowerInvariant(),
            Name = command.Name,
            Role = UserRole.Member,
            CreatedAt = DateTime.UtcNow
        };

        return Result<User>.Success(user);
    }

    public bool CanPromoteToAdmin(User currentUser, User targetUser)
    {
        return currentUser.Role == UserRole.Admin
            && targetUser.Role != UserRole.Admin;
    }
}

6. API Contracts

Document your API endpoints with request/response examples:

POST /api/users - Create a new user

Request:

{
  "email": "user@example.com",
  "name": "John Doe",
  "role": "member"
}

Response (201):

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "email": "user@example.com",
  "name": "John Doe",
  "role": "member",
  "createdAt": "2024-01-15T10:30:00Z"
}

Errors:

• 400: Validation error

• 409: Email already exists

7. Implementation Checklist

This is the heart of the implementation plan—a detailed checklist organized by phase:

## Implementation Checklist

### Phase 1: Foundation

**Project Setup:**
- [x] Create solution and project structure
- [x] Configure EditorConfig and code analysis
- [x] Set up xUnit test projects
- [x] Create GitHub Actions CI pipeline

**Domain Layer:**
- [x] Define User entity and UserRole enum
- [x] Implement UserService with business logic
- [x] Create UserValidator with FluentValidation
- [x] Write unit tests for domain logic (100% coverage)

### Phase 2: Infrastructure

**Database:**
- [x] Create SQL migration scripts
- [x] Implement UserRepository with Dapper
- [x] Write repository integration tests

### Phase 3: API Layer

**Endpoints:**
- [x] POST /api/users (create)
- [ ] GET /api/users/{id} (read)
- [ ] PUT /api/users/{id} (update)
- [ ] DELETE /api/users/{id} (delete)
- [ ] GET /api/users (list with pagination)

**Authentication:**
- [ ] JWT token generation
- [ ] Token validation middleware
- [ ] Role-based authorization

Update the checklist as you work. It provides:

• Clear progress visibility

• Natural stopping points

• Context for resuming work

• Documentation of what’s complete

8. Code Patterns

Document the patterns you’ll use throughout the codebase:

// Repository pattern with Dapper
public class UserRepository : IUserRepository
{
    private readonly IDbConnectionFactory _connectionFactory;

    public UserRepository(IDbConnectionFactory connectionFactory)
    {
        _connectionFactory = connectionFactory;
    }

    public async Task<User?> GetByIdAsync(Guid id)
    {
        using var connection = _connectionFactory.CreateConnection();
        return await connection.QuerySingleOrDefaultAsync<User>(
            "SELECT Id, Email, Name, Role, CreatedAt, LastLogin FROM Users WHERE Id = @Id",
            new { Id = id });
    }

    public async Task<User> CreateAsync(User user)
    {
        using var connection = _connectionFactory.CreateConnection();
        await connection.ExecuteAsync(
            @"INSERT INTO Users (Id, Email, Name, Role, CreatedAt)
              VALUES (@Id, @Email, @Name, @Role, @CreatedAt)",
            user);
        return user;
    }
}

// Result type for explicit error handling
public class Result<T>
{
    public bool IsSuccess { get; }
    public T? Value { get; }
    public string[] Errors { get; }

    private Result(bool isSuccess, T? value, string[] errors)
    {
        IsSuccess = isSuccess;
        Value = value;
        Errors = errors;
    }

    public static Result<T> Success(T value) =>
        new(true, value, Array.Empty<string>());

    public static Result<T> Failure(params string[] errors) =>
        new(false, default, errors);
}

The Development Workflow

Here’s how a typical development session looks with planning-driven development:

1. Session Start

You: "Let's continue with the implementation plan. We're on Phase 2.
Read IMPLEMENTATION_PLAN.md and let's work on the GET /api/users/{id} endpoint."

Agent: [Reads plan, understands context, sees patterns]
"I see we're implementing the user retrieval endpoint. Based on the plan,
I'll follow the repository pattern established in Phase 1. Let me start
with the tests following TDD..."

2. Implementation

The agent works through the checklist items, following established patterns from the plan. Because the patterns are documented, there’s consistency. Because the checklist exists, there’s clarity on what “done” means.

3. Session End

You: "Good progress. Update the checklist in the implementation plan
to mark what we completed."

Agent: [Updates checklist, marks items complete]
"Updated. We completed 3 of 5 endpoint implementations in Phase 2.
Next session we can tackle the remaining endpoints."

4. Resume Later

The next day, with a fresh context window:

You: "Continue with IMPLEMENTATION_PLAN.md, Phase 2."

Agent: [Reads plan, sees exactly where you left off]
"I see we have PUT and DELETE endpoints remaining. Let me continue
with the update endpoint..."

No re-explanation needed. The plan carries all context.

Refining Plans with GenAI

One of the most powerful aspects of this approach is using the GenAI agent to help create and refine the plans themselves.

Initial Planning Session

You: "I need to build a user management API for our new application.
Let me describe the requirements, and then help me create a planning document..."

[Describe business requirements, constraints, existing systems]

Agent: [Asks clarifying questions, proposes structure]
"Based on what you've described, here are some questions:
1. What authentication method should we use (JWT, OAuth)?
2. What are the user roles and permissions?
3. Are there existing patterns from other services we should follow?

Let me start drafting a planning document..."

Iterative Refinement

You: "The database section needs more detail. We need to handle
status transitions with audit trails."

Agent: [Expands section with specific table designs, constraints, indexes]

You: "The testing strategy should emphasize TDD. Reference my post
about taming GenAI agents with TDD."

Agent: [Updates testing section to align with TDD methodology]

Review and Finalize

Once the plan feels complete:

You: "Review the entire implementation plan. Identify any gaps,
inconsistencies, or missing details."

Agent: "I notice:
1. Phase 3 mentions notifications but there's no notification service design
2. The API contract doesn't specify pagination for list endpoints
3. Error codes are defined but error message format isn't standardized

Want me to address these?"

Common Planning Document Patterns

After analyzing planning documents across many projects, these patterns consistently appear in effective plans:

Decision Rationale Tables

DecisionOptions ConsideredChoiceRationaleData AccessEntity Framework, DapperDapperSimpler, explicit SQL, better GenAI compatibilityAuthJWT, SessionJWTStateless, works with microservicesQueueRabbitMQ, Kafka, Azure Service BusAzure Service BusTeam expertise, cloud-native

Status Tracking

PhaseStatusNotesPhase 1: FoundationCompleteAll tests passingPhase 2: Core APIIn Progress3/5 endpoints donePhase 3: NotificationsNot StartedBlocked on email service access

Risk Register

RiskImpactLikelihoodMitigationThird-party API changesHighMediumVersion-pin dependencies, integration testsDatabase migration failuresHighLowTest migrations in staging, backup before prod

Open Questions

1. Email template approval: Need marketing sign-off on notification templates

   • Status: Pending

   • Owner: Sarah

2. Rate limiting strategy: How aggressive should we be?

   • Options: 100/min, 1000/min, no limit initially

   • Leaning: 100/min to start, adjust based on usage

Scaling to Large Projects

For substantial projects, consider:

Hierarchical Planning

docs/
├── PLANNING.md                    # High-level (stakeholder-facing)
├── IMPLEMENTATION_PLAN.md         # Overall technical plan
├── phases/
│   ├── PHASE_1_FOUNDATION.md      # Detailed phase plan
│   ├── PHASE_2_CORE_API.md
│   └── PHASE_3_NOTIFICATIONS.md
└── designs/
    ├── DATABASE_DESIGN.md         # Deep-dive documents
    ├── API_SPECIFICATION.md
    └── SECURITY_MODEL.md

Version Control for Plans

Treat planning documents like code:

• Commit changes with meaningful messages

• Review significant plan changes

• Tag releases when plans are “approved”

Team Synchronization

When working with teams:

• Plans become the source of truth

• Code reviews reference the plan

• Deviations from plan require discussion

• Plan updates follow change control

Practical Tips

Start Small

Don’t try to plan everything upfront. Begin with:

1. An initial overview

2. A list of phases

3. A simple checklist

Expand as you learn more about the problem.

Keep It Living

The plan should evolve. When you discover something during implementation:

1. Update the plan

2. Document why you changed course

3. Adjust remaining phases if needed

Reference Liberally

In your plan, reference:

• Other planning documents (exploring specific decisions in more depth)

• External documentation

• Your own blog posts or team wikis

• Related codebases

The more context, the better.

Include Code Examples

Don’t be afraid to put code in your planning documents. Actual code examples:

• Set the style for the project

• Provide copy-paste starting points

• Reduce ambiguity about patterns

Timebox Planning

I typically spend:

• 2-4 hours on initial planning document

• 4-8 hours on detailed implementation plan

• Ongoing updates as we implement

The upfront investment pays off exponentially.

The Results

Since adopting planning-driven development:

• First-pass accuracy consistently reaches 90-95%

• Context switching became trivial (just reference the plan)

• Stakeholder communication improved (share the planning document)

• Decision archaeology simplified (rationale is documented)

The planning document becomes an asset that outlives the implementation itself, serving as documentation, training material, and historical record.

Conclusion

The shift from prompt-engineering code to planning-first development is the single biggest productivity multiplier I’ve found when working with GenAI agents. Instead of fighting with code corrections, you refine documents. Instead of re-explaining context, you reference plans. Instead of debugging misunderstandings, you clarify upfront.

Yes, a 48-page implementation plan sounds like a lot of reading. But compare that to days of debugging misaligned implementations, or weeks of refactoring code that solved the wrong problem.

Planning documents are cheap to write, cheap to edit, and expensive not to have.

The next time you start a new feature or project with a GenAI agent, resist the urge to start prompting for code. Instead, say: “Let’s create a planning document first.” Then watch as your development sessions become focused, efficient, and productive.

For the foundation of this approach, see Planning-First Development: How Markdown Documents Drive Structured AI-Assisted Development.

For why I always start with domain models, see Domain-First Development: Building Robust Applications from the Core Out.

For combining planning with test-driven development, see Taming GenAI Agents Like Claude Code with Test-Driven Development.

The Long Search for the Right Tool

For years, I wanted a simple time tracking app tailored to how developers actually work. Existing solutions were either too complex with features I’d never use, too generic to capture development-specific context, or subscription-based for functionality that should live locally on my device.

What I wanted was straightforward:

• Track time against projects and work items (tickets, issues)

• Categorize by task type (feature work, bug fixes, meetings, code review)

• Generate reports for billing or personal productivity analysis

• Export data in a standard format

• Work offline with local storage

• No subscription, no account, no server dependency

Nothing quite fit. So I built it myself.

Building with Claude Code

DevHours is my first mobile app. I built it with significant assistance from Claude Code, Anthropic’s AI coding assistant. The combination of Claude’s code generation capabilities with my architectural decisions and domain expertise made the development process remarkably efficient.

The entire codebase was developed using test-driven development (TDD). Domain models were written test-first, with 148 tests ensuring correctness across all CRUD operations, database migrations, and business logic. Claude Code helped maintain this discipline throughout, generating test cases and implementation code in lockstep.

The source is open under GPL v3: github.com/codepasture/devhours

Tech Stack

• Framework: React Native with Expo SDK 54

• Language: TypeScript (strict mode)

• Navigation: React Navigation 7 with bottom tabs

• UI Components: React Native Paper (Material Design 3)

• State Management: Zustand

• Database: SQLite via expo-sqlite (sql.js for web)

• Testing: Jest with better-sqlite3 for fast in-memory tests

The architecture follows clean separation of concerns: domain models, infrastructure (repositories, database), screens/components, and typed Zustand stores.

Key Features

Timer and Manual Entry Start a timer when you begin work, or create entries manually for time you forgot to track. The running total shows completed time plus any active timer.

Projects and Work Items Organize time by project with custom colors. Within projects, create work items with external IDs (for JIRA tickets, GitHub issues, etc.) to track exactly what you worked on.

Task Types Categorize entries: Feature, Bug Fix, Meeting, Code Review, Refactor, Documentation, Testing, Research, Planning, Ops.

Reports View time breakdowns by day, project, or task type. Filter by custom date ranges.

Export Generate CSV files for billing, invoicing, or importing into other systems.

Themes Light, dark, and auto modes.

Lessons Learned

Building a React Native app for the first time surfaced several gotchas worth documenting:

Always use npx expo install for native modules. Using npm install directly can install versions incompatible with your Expo SDK, causing cryptic runtime crashes. Expo’s CLI selects SDK-compatible versions automatically.

UUID generation requires expo-crypto. The standard uuid package depends on crypto.getRandomValues(), which isn’t available in React Native. Use Crypto.randomUUID() from expo-crypto instead.

Avoid new architecture flags in Expo Go. Features like newArchEnabled and Android’s edgeToEdgeEnabled require custom development builds and cause errors in Expo Go.

Timezone handling matters. Early versions had a bug where evening entries appeared on the wrong day. Date operations need careful handling of local vs. UTC time.

iOS time pickers have quirks. The maximumDate prop was clamping selected times unexpectedly. Sometimes the platform-specific behavior requires platform-specific workarounds.

What’s Next

I’m actively using DevHours to track my own development time. It does exactly what I wanted: simple, focused time tracking without the overhead of complex project management features I don’t need.

The app is free. The source is open. If you’ve been looking for a developer-focused time tracker, give it a try.

This is Part 2 of the JSNTM (Just Say No to Monoliths) series. In that post, I committed to no longer creating monolithic services. But the same principle applies to the frontend.

The Frontend Monolith Problem

We’ve been fighting monoliths on the backend for years. Microservices, bounded contexts, independent deployability—we know the patterns. Yet on the frontend, we often build massive single-page applications where every team commits to the same repo, every feature ships together, and a bug in one component can block the entire release.

The same excuses apply: “It’s easier to set up one project.” “Shared components are simpler in a monorepo.” “The overhead of separate deployments isn’t worth it.”

Sound familiar?

Micro-Frontends: The Same Solution

Micro-frontends apply microservice principles to the UI layer. Each bounded context owns its frontend. Teams deploy independently. Technology choices can vary by module. The shell orchestrates composition without coupling.

The concept isn’t new, but the implementation has historically been painful. Module federation configuration, webpack complexity, runtime dependency management—the overhead rivaled the backend service creation problem I described in Part 1.

GenAI changes this too.

A Working Reference Implementation

I’ve built a reference implementation demonstrating these patterns:

Live Demo:

https://mfe-svelte-shell-example.nathanfox.net

Source Code: https://github.com/nathanfox/mfe-svelte-shell-example

The architecture: a Svelte 5 shell orchestrating five different micro-frontends, each built with a different framework—React, Vue, Svelte, SolidJS, and Angular. All running together, all independently deployable.

Why Svelte for the Shell?

The shell is the foundation everything builds on. Its runtime ships with every page load. Size and performance matter.

Svelte 5 compiles to vanilla JavaScript with a ~1.6-3 KB runtime. React’s runtime is ~40+ KB. When your shell’s job is to load and orchestrate other frameworks, you don’t want framework overhead competing with your actual applications.

Beyond size:

• No Virtual DOM overhead

• Built-in state management with runes

• Clean syntax that GenAI tools generate reliably

• No framework conflicts—it compiles away

The shell should be invisible infrastructure. Svelte achieves this.

The Architecture

┌─────────────────────────────────────────────────────────────┐
│                        Svelte Shell                         │
│  ┌─────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
│  │ Header  │  │ Navigation  │  │     MFE Container       │  │
│  │ (Auth)  │  │  (Dynamic)  │  │  (Mount/Unmount Point)  │  │
│  └─────────┘  └─────────────┘  └─────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│  React MFE    │   │   Vue MFE     │   │  Svelte MFE   │
│  (Dashboard)  │   │  (Analytics)  │   │  (Reports)    │
│   Port 5001   │   │   Port 5002   │   │   Port 5003   │
└───────────────┘   └───────────────┘   └───────────────┘

Each MFE is a self-contained application with its own build, its own dependencies, and its own deployment pipeline.

The MFE Lifecycle Contract

Every micro-frontend exports three functions:

export async function bootstrap(props: MfeProps): Promise<void>
export async function mount(props: MfeProps): Promise<void>
export async function unmount(props: MfeProps): Promise<void>

The shell provides everything an MFE needs:

interface MfeProps {
  container: HTMLElement;           // Where to render
  basePath: string;                 // Route prefix
  auth: AuthContext;                // User state, login/logout
  eventBus: EventBus;               // Cross-MFE communication
  navigate: (path: string) => void; // Shell navigation
  theme: 'light' | 'dark';
  navigation: NavigationApi;        // Dynamic route registration
  cache: MfeCache;                  // Per-MFE state cache
}

This contract is framework-agnostic. React, Vue, Svelte, Angular—they all implement the same interface. The shell doesn’t care what’s inside the MFE, only that it honors the lifecycle.

Framework Implementation Examples

React:

import { createRoot } from 'react-dom/client';
import App from './App';

let root: Root | null = null;

export async function mount(props: MfeProps) {
  root = createRoot(props.container);
  root.render(<App {...props} />);
}

export async function unmount() {
  root?.unmount();
}

Vue:

import { createApp } from 'vue';
import App from './App.vue';

let app: App | null = null;

export async function mount(props: MfeProps) {
  app = createApp(App, props);
  app.mount(props.container);
}

export async function unmount() {
  app?.unmount();
}

Svelte:

import { mount, unmount as svelteUnmount } from 'svelte';
import App from './App.svelte';

let app: any = null;

export async function mount(props: MfeProps) {
  app = mount(App, { target: props.container, props });
}

export async function unmount() {
  svelteUnmount(app);
}

Same pattern, different frameworks. The shell loads each MFE dynamically and calls these lifecycle hooks.

Native Federation: No Webpack Required

The implementation uses Native Federation—ES Modules loaded directly by the browser, no Module Federation webpack plugin needed.

Each MFE builds to a single remoteEntry.js:

// vite.config.ts
build: {
  lib: {
    entry: 'src/main.tsx',
    fileName: 'remoteEntry',
    formats: ['es'],
  },
}

The shell imports dynamically:

const module = await import(/* @vite-ignore */ mfe.entry);
await module.mount(props);

This is future-proof. No bundler lock-in. Standard ES Modules that browsers understand natively.

Manifest-Based Registration

MFEs register via a static JSON manifest:

{
  "id": "react-example",
  "name": "React Dashboard",
  "entry": "/mfes/react-example/remoteEntry.js",
  "route": "/react",
  "menu": {
    "label": "Dashboard",
    "icon": "📊",
    "order": 1,
    "children": [
      { "label": "Overview", "path": "/react", "icon": "🏠" },
      { "label": "Analytics", "path": "/react/analytics", "icon": "📈" }
    ]
  }
}

Adding a new MFE means adding an entry to the manifest and deploying the bundle. The shell discovers it automatically.

Shell-MFE Communication

MFEs communicate with the shell through an event bus:

// MFE emits event to shell
props.eventBus.emit('report:generated', { id: 123, name: 'Q4 Report' });

// Shell listens and can update shared state, trigger notifications, etc.
eventBus.on('report:generated', (data) => {
  showNotification(`Report ${data.name} created`);
});

Since only one MFE is mounted at a time (navigation unmounts the previous MFE), direct MFE-to-MFE communication isn’t the primary use case. Instead, the event bus handles MFE-to-shell communication: auth state changes, navigation requests, notifications, and analytics. The shell’s state cache can persist data between MFE sessions when needed.

Dynamic Route Registration

MFEs can register routes at runtime based on user permissions:

export async function mount(props: MfeProps) {
  const routes = [
    { label: 'Overview', path: props.basePath, icon: '🏠' },
    { label: 'Analytics', path: `${props.basePath}/analytics`, icon: '📈' },
  ];

  if (props.auth.user?.roles?.includes('admin')) {
    routes.push({
      label: 'Admin',
      path: `${props.basePath}/admin`,
      icon: '🛡️',
    });
  }

  props.navigation.registerRoutes(routes);
  // ...
}

The shell’s secondary navigation updates automatically. Admin users see admin routes; regular users don’t.

Deployment

The build process is straightforward:

# Build all MFEs in parallel
npm run build:mfes

# Build shell
npm run build:shell

# Copy MFE bundles into shell dist
npm run copy:mfes

Output structure:

dist/
├── index.html
├── manifest.json
└── mfes/
    ├── react-example/remoteEntry.js
    ├── vue-example/remoteEntry.js
    ├── svelte-example/remoteEntry.js
    └── ...

Deploy to any static host. The demo runs on Netlify with a single configuration file.

Note: This build process is simplified for the example—all MFEs build together and copy into a single deployment. In production, each MFE builds and deploys with its owning microservice. The inventory service’s CI/CD pipeline builds both the API and its MFE bundle. The manifest points to each service’s hosted assets:

{
  "id": "inventory",
  "entry": "https://inventory-api.example.com/mfe/remoteEntry.js",
  "route": "/inventory"
}

The shell and each microservice deploy independently. When the inventory team ships a new feature, they deploy their service—API and UI together. No coordination required.

The JSNTM Connection

This is microservices for the frontend:

• Bounded contexts - Each MFE owns a domain (dashboard, analytics, reports)

• Independent deployability - Ship features without coordinating releases

• Technology flexibility - Choose the right framework for each module

• Team autonomy - Teams own their MFE end-to-end

• Fault isolation - A bug in one MFE doesn’t crash the others

The same reasons we decompose backend monoliths apply to frontend monoliths.

The key insight: a microservice can own its MFE.

Your inventory microservice doesn’t just expose an API—it ships with its own UI module. The same repo, the same team, the same deployment pipeline. When you deploy the inventory service, you deploy its frontend too. The bounded context is complete from database to UI.

This is true vertical slicing. No more coordinating between “backend team” and “frontend team” for a single feature. The service owns everything.

GenAI and MFE Creation

Here’s where it connects to the original JSNTM post.

Creating a new MFE with this architecture means:

• Copy an existing MFE folder

• Update the manifest entry

• Implement the three lifecycle functions

• Build and deploy

With GenAI coding agents, this is a conversation:

“Create a new MFE like the React example, but for inventory management. It should have three tabs: Stock Levels, Reorder Alerts, and Supplier Contacts.”

The agent copies the pattern, scaffolds the components, wires up the lifecycle hooks. You review and refine. Hours, not days.

The same Example-Driven Development pattern applies. Your existing MFEs become the specification for new ones.

A Blueprint, Not a Finished Product

This implementation is intentionally a starting point—a blueprint to build upon, not a production-ready framework.

The patterns are established, but your needs will differ. Some possibilities to extend:

• Dynamic shell menu updates - MFEs could register top-level navigation items, not just secondary routes

• Shared design tokens - CSS custom properties, fonts, and styling conventions loaded by the shell for visual consistency across MFEs

• Cross-MFE state synchronization - Persist and sync state across MFE sessions via the shell

• MFE-to-MFE messaging - Queue events for MFEs that aren’t currently mounted

• Lazy manifest loading - Discover MFEs dynamically from a backend service

• A/B testing support - Load different MFE versions based on user segments

• Analytics integration - Shell-level tracking of MFE mount/unmount, navigation, errors

The point is demonstrating the architecture and lifecycle contract. Fork it, extend it, make it yours.

Try It Yourself

Live Demo:

https://mfe-svelte-shell-example.nathanfox.net

Source Code: https://github.com/nathanfox/mfe-svelte-shell-example

The repository includes:

• Complete shell implementation with auth, navigation, event bus

• Five framework examples (React, Vue, Svelte, SolidJS, Angular)

• Comprehensive documentation in the docs/ folder

• Development and production configurations

Clone it, run npm install && npm run dev, and you’ll have a working MFE environment in minutes. Then extend it for your use case.

The Commitment Continues

Part 1 was backend: no more monolithic services.

Part 2 is frontend: no more monolithic SPAs.

The patterns exist. The tooling is mature. GenAI makes the setup trivial. The only barrier is discipline.

JSNTM: Just Say No to Monoliths—on both sides of the stack.

This post is part of the JSNTM series on eliminating monoliths with GenAI-assisted development. See also Part 1: Just Say No to Monoliths in the GenAI Age.

This post was written with Claude Code. I described the concept, provided the reference implementation, and Claude helped draft and structure the content. I reviewed and edited the result. The logo was generated with ChatGPT. This is how I work now. You can see the revision history in my blog posts repo.

The Pledge

I’m making a commitment: I will no longer create monolithic applications or services, no matter how small the project.

This isn’t aspirational thinking or architectural idealism. It’s a practical decision enabled by GenAI coding agents. The calculus that once made monoliths the “pragmatic choice” has fundamentally changed.

The Old Excuse

For years, the conversation went like this:

“This should really be its own service.”

“Yes, but setting up a new service takes 3-5 days. Let’s just add it to the existing one.”

We knew it would stay there. One bounded context bled into another. Services that started focused accumulated unrelated responsibilities. We knew better, but the overhead of doing it right exceeded the immediate cost of doing it wrong.

The result? Systems with 25 services that should have been 40 or more. Monoliths wearing microservice clothing. Technical debt disguised as pragmatism.

What Creating a New Service Actually Required

Setting up a new microservice traditionally meant:

1. Repository Setup - Create repo, configure branch policies, add team access

2. Project Scaffolding - Solution files, folder structure, configuration

3. Boilerplate Code - Startup code, dependency injection, authentication

4. Infrastructure - Health checks, logging, metrics, configuration management

5. Containerization - Dockerfile, docker-compose for local development

6. Orchestration - Kubernetes manifests, service definitions, ingress rules

7. CI/CD Pipeline - Build, test, and deployment automation

8. Database Setup - Schema design, migrations, connection configuration

9. Documentation - README, API documentation, architecture notes

Three to five days of tedious work before writing a single line of business logic.

No wonder we cut corners.

The GenAI Transformation

With tools like Claude Code, that 3-5 day overhead collapses to 2-4 hours—including review and refinement.

GenAI excels at exactly the work we avoided:

• Project scaffolding and structure

• Boilerplate startup code

• Dockerfile generation

• Kubernetes manifests

• CI/CD pipeline templates

• Database schema scaffolding

• API contract definitions

• Test scaffolding

The repetitive, pattern-based work that made service creation burdensome is precisely what AI handles best. You describe the service boundaries, the data it owns, the contracts it exposes—and the scaffolding materializes.

Better yet, if you already have microservices, they become templates for new ones. Point the AI at an existing service and say “create a new service like this one, but for X.” This is Example-Driven Development—your existing codebase becomes the specification. The patterns, conventions, and infrastructure decisions you’ve already made get replicated automatically.

This isn’t about AI writing your business logic. It’s about AI eliminating the friction that pushed you toward architectural compromise.

The New Standard

When service creation is cheap, the architecture question changes.

Before GenAI: “Is this different enough to justify the overhead of a new service?”

After GenAI: “Is this a distinct bounded context with its own data ownership?”

If yes, it gets its own service. Full stop.

The decision criteria should be architectural merit, not implementation burden. GenAI makes that possible.

Decision Framework

Create a new service when:

• It represents a distinct bounded context

• It has clear data ownership (its own database or data store)

• It could reasonably scale independently

• It has a different deployment cadence

• A different team could own it

• It’s a significant new feature area

Keep functionality in an existing service when:

• It’s a new endpoint within an existing domain

• It shares most data with existing functionality

• It’s a small utility function

• It’s tightly coupled to existing business logic

When uncertain, ask: “If another team were building this, what would they need from us?”

If the answer is “just the database,” it belongs in the existing service. If the answer is “a well-defined API contract,” it’s a candidate for extraction.

The Micro-Frontend Parallel

This principle extends beyond backend services to the user interface.

With micro-frontends (MFEs), each microservice can own its UI components. The same GenAI-enabled workflow that makes backend service creation trivial applies to frontend modules.

Consider a shell application that composes independently deployable frontend modules:

• Each bounded context owns its UI

• Teams can deploy UI changes independently

• Technology choices can vary by module

• The frontend mirrors the backend architecture

I’ll be exploring this pattern in depth in a future post, including a reference implementation demonstrating how to build a Svelte-based micro-frontend shell with dynamically loaded modules.

What This Enables

When you stop compromising on architecture:

Independent Deployability - Each service deploys on its own schedule. A bug fix in one area doesn’t require coordinating with unrelated changes.

Clear Ownership - No more debates about which service owns which functionality. Boundaries are explicit.

Independent Scaling - Scale the services that need it without over-provisioning everything else.

Fault Isolation - Problems stay contained. A failure in one bounded context doesn’t cascade.

Technology Flexibility - Different services can use different technologies where appropriate.

Smaller Codebases - GenAI tools work better with focused codebases. Smaller context windows, more accurate suggestions.

The Counter-Argument

“But microservices add operational complexity!”

True. But this complexity exists whether you acknowledge it or not. A monolith with mixed concerns has the same logical complexity—it’s just hidden behind a single deployment unit. When something breaks, you’re still debugging across conceptual boundaries.

Explicit boundaries don’t create complexity. They make existing complexity visible and manageable.

And with modern orchestration platforms and GenAI-assisted operations, the operational overhead of running multiple services has never been lower.

The Commitment

This is my line in the sand:

Every new bounded context gets its own service.

The tools exist to make this practical. The patterns are established. The only remaining barrier is discipline.

GenAI hasn’t just changed how we write code. It’s changed which architectural compromises are acceptable. The old excuses don’t apply anymore.

No more “just add it to the existing service for now.” No more monoliths, even small ones.

The JSNTM pledge: Just Say No to Monoliths.

This post is part of a series on leveraging GenAI tools for better software architecture. For related reading on GenAI-assisted development practices, see Achieving 4x+ Productivity Gains with GenAI Coding Agents and Planning-First Development with Claude Code.

This post was written with Claude Code. I described the concept, provided context from my own architecture decisions, and Claude helped draft and structure the content. I reviewed and edited the result. The logo was generated with ChatGPT. This is how I work now. You can see the revision history in my blog posts repo.

I’ve been using Claude Code to estimate story points with surprisingly accurate results. The process leverages the agent’s ability to read external systems, analyze code, and reason about complexity—exactly what a developer does mentally during estimation.

The Estimation Workflow

The workflow involves several steps that mirror how an experienced developer would approach estimation:

1. Read the Work Ticket

First, the agent reads the work ticket to understand the requirements. This workflow assumes you have CLI tools that allow the agent to interact with your issue tracker (Jira, GitHub, Linear, Azure DevOps, or whichever system you use):

Read PROJ-456 and summarize the requirements

The agent uses these CLI tools to pull ticket descriptions, acceptance criteria, and any linked documentation directly from your issue tracker.

2. Plan the Implementation

Next, the agent creates an implementation plan:

Based on PROJ-456, create a plan for what needs to be done to implement this feature

This step forces the agent to think through the actual work—what files need to change, what new code is required, what tests need to be written, and what edge cases exist. The plan becomes the basis for the estimate.

3. Analyze Historical Data

Here’s where the agent’s capabilities really shine. It reads through:

• Git commit history: Looking at recent commits to understand the codebase velocity

• Historical story point allocations: Reading past tickets and their estimates from your issue tracker

• Lines of code per story point: Calculating rough metrics from completed work

Look at the last 10 completed tickets in PROJ, read their story points,
and analyze the associated git commits to understand lines of code and complexity per point

4. Generate the Estimate with Justification

Finally, the agent produces an estimate with clear reasoning:

Based on your implementation plan and historical analysis, estimate story points for PROJ-456
with detailed justification

The agent considers factors like:

• Lines of code: How does the expected change size compare to historical tickets?

• Code complexity: Is this touching complex algorithms, simple CRUD, or integration points?

• Testing requirements: Does this need extensive test coverage?

• Risk factors: Are there unknowns or dependencies that add uncertainty?

• Comparison to similar work: How does this compare to past tickets the team has completed?

Why This Works

GenAI agents are well-suited for estimation because they can:

1. Process large amounts of context: Read entire ticket histories, codebases, and commit logs

2. Identify patterns: Recognize similarities between new work and completed work

3. Provide consistent reasoning: Apply the same analysis framework every time

4. Show their work: Explain exactly why they arrived at a particular estimate

The estimates I’ve received have been remarkably reasonable—neither the chronic underestimation nor padding that often plagues human estimates.

Real-World Results

The proof is in the productivity. My historical baseline was approximately 20 story points per month within a standard deviation—a consistent measure over time.

After integrating GenAI agents into my workflow—not just for estimation, but for the actual development work—I completed 128 story points in 4 weeks.

That’s a 6x increase in throughput.

This isn’t about the estimates being inflated. The same estimation methodology was applied, the same team reviewed the work, and the same definition of done was met. GenAI agents simply allow you to move faster through the actual implementation while maintaining quality.

Setting Up Agent-Based Estimation

To enable this workflow, you need:

1. Issue tracker API access: Scripts or CLI tools to read tickets and story points

2. Git repository access: The agent needs to read commit history

3. Clear prompting: Guide the agent through the estimation steps

Example prompt to kick off the full workflow:

I need you to estimate story points for PROJ-456. Please:

1. Read the ticket and summarize the requirements
2. Create an implementation plan
3. Look at the last 10 completed tickets, read their story points, and analyze
   the associated commits for lines of code and complexity
4. Provide a story point estimate with detailed justification comparing to historical work

Considerations

A few things to keep in mind:

• Calibration matters: The agent needs access to historical data from your specific team to calibrate estimates

• Review the reasoning: Always read the justification—it helps you catch misunderstandings

• Team context: Story points are team-specific; the agent learns your team’s velocity from your data

• Refinement over time: The more historical data available, the better the estimates become

Conclusion

GenAI agents bring a data-driven approach to story point estimation. By analyzing historical patterns, planning implementation details, and comparing to past work, they produce well-reasoned estimates that align with team velocity.

More importantly, these same agents can then help you execute the work at speeds previously unimaginable. When you combine accurate estimation with accelerated delivery, you get predictable planning and dramatically improved throughput.

The 128 story points in 4 weeks wasn’t an anomaly—it’s the new baseline when GenAI agents are integrated effectively into your development workflow.

Using Jira for Story Points

If your team uses Jira, you’ll need scripts that allow the agent to read and update story points. The Atlassian CLI doesn’t provide direct support for story point operations, so I created custom bash scripts that interact with the Jira REST API.

These scripts enable the agent to:

• Read story points for one or more tickets to analyze historical estimates

• Update story points after the agent completes its estimation analysis

For setup instructions and the scripts themselves, see Jira Story Points Scripts for GenAI Agents.

The Problem: No Atlassian CLI Support

I could not find a way to accomplish story point read/update operations through the Atlassian CLI. The official Atlassian CLI tools focus on other operations, and while there are third-party alternatives, I wanted something lightweight and portable that could easily be invoked by a GenAI agent.

The Solution: Custom Bash Scripts

Working with Claude Code, I created two simple bash scripts that use the Jira REST API directly:

• jira-read-storypoints.sh - Read story points for one or more tickets

• jira-update-storypoints.sh - Update story points for one or more tickets

Full documentation and setup instructions: dev.nathanfox.net/scripts/jira-storypoints/

Script Features

Both scripts share common characteristics that make them suitable for GenAI agent interaction:

• Clear error messages: When environment variables are missing, the scripts provide helpful setup instructions

• Batch operations: Process multiple tickets in a single invocation

• Structured output: Consistent, parseable output format for agent consumption

• Exit codes: Return appropriate exit codes (success/failure count) for programmatic handling

Reading Story Points

# Single ticket
jira-read-storypoints.sh PROJ-123
# Output: PROJ-123: 5 points - Implement user authentication

# Multiple tickets
jira-read-storypoints.sh PROJ-123 PROJ-124 PROJ-125

Updating Story Points

# Single ticket
jira-update-storypoints.sh PROJ-123 3

# Multiple tickets (pairs of ticket and points)
jira-update-storypoints.sh PROJ-123 3 PROJ-124 5 PROJ-125 8

Environment Setup

The scripts require four environment variables:

export JIRA_URL=’https://mycompany.atlassian.net’
export JIRA_EMAIL=’your-email@example.com’
export JIRA_API_TOKEN=’your_api_token_here’
export JIRA_STORY_POINTS_FIELD=’customfield_XXXXX’

Finding Your Story Points Custom Field ID

Story points in Jira are stored as a custom field, not a standard field. The field ID (e.g., customfield_10016) is unique to each Jira instance since IDs are assigned sequentially as fields are created.

Option 1: Jira Admin UI

1. Go to Jira Settings (gear icon) → Issues → Custom fields

2. Find “Story Points” or “Story point estimate” in the list

3. Click on it to view details

4. The field ID is in the URL: .../customFields/configure?fieldId=customfield_XXXXX

Option 2: API Query

curl -s -u “your-email@example.com:$JIRA_API_TOKEN” \
  “$JIRA_URL/rest/api/3/field” | jq ‘.[] | select(.name | test(”story point”; “i”)) | {name, id}’

This returns something like:

{
  “name”: “Story point estimate”,
  “id”: “customfield_10016”
}

Option 3: Inspect a Ticket

Query any ticket that has story points set and look for the value among custom fields:

curl -s -u “your-email@example.com:$JIRA_API_TOKEN” \
  “$JIRA_URL/rest/api/3/issue/PROJ-123” | jq ‘.fields | to_entries[] | select(.key | startswith(”customfield_”))’

GenAI Agent Integration

These scripts were specifically designed to be invoked by GenAI coding agents. A typical workflow might look like:

1. Agent receives a task: “Estimate PROJ-456 and update Jira”

2. Agent reviews the ticket requirements and codebase

3. Agent calls jira-update-storypoints.sh PROJ-456 5 to set the estimate

4. Agent confirms the update with jira-read-storypoints.sh PROJ-456

The clear output format makes it easy for agents to verify operations succeeded and extract relevant information from the response.

For a complete workflow using these scripts for agent-based estimation, see Using GenAI Agents to Estimate Story Points.

Why Bash Scripts?

Bash scripts work well for GenAI agent tooling because:

• Universal availability: Present on virtually all development machines

• No dependencies: Beyond curl and jq, no additional packages needed

• Easy invocation: Simple command-line interface that agents understand

• Portable: Copy to any machine with the required environment variables

• Transparent: Easy to audit what the script does

I wrote this blog post with Claude Code. I described what I wanted to explore, we discussed the structure together, and it generated the draft. I’m editing as we go. Even writing—documentation, blog posts, prose—is no longer “writing” in the classic sense. Which rather proves the point.

The Title That No Longer Fits

For decades, the answer was simple. You wrote code. You were a programmer, a developer, a software engineer. The title matched the activity. But something has shifted.

With GenAI coding agents like Claude Code, Cursor, and GitHub Copilot, the day-to-day reality of building software looks fundamentally different. You might spend more time describing what you want than typing the implementation. You review and refine more than you write from scratch. You orchestrate and direct rather than line-by-line construct.

So what are we now?

The Framings We’re Trying On

The industry hasn’t settled on new terminology, but several framings are emerging:

Code Orchestrator - You’re conducting a symphony. Multiple AI agents, different specialized tools, various codebases. Your job is directing their focus, combining their outputs, ensuring coherence. Less about writing every line, more about coordinating the ensemble.

Intent Translator - The core skill becomes articulating what you want with enough precision that AI can execute it. You’re bridging human goals to machine-executable specifications. Vague requirements produce vague code. Precise intent produces working software.

Code Curator - Like an editor working with writers. You review, refine, accept, reject, and shape AI-generated code. Quality control and taste become paramount. The AI proposes; you dispose.

Systems Architect - You focus on high-level design, constraints, integration patterns. The “what” and “why” over the “how.” Implementation details get delegated while you hold the vision.

Verification Engineer - Your value is knowing what correct looks like. You validate outputs, catch edge cases the AI misses, ensure the generated code actually does what it claims. The AI writes; you verify.

None of these fully capture it. Perhaps because the role is genuinely multifaceted now.

The New Skills That Matter

Whatever we call ourselves, certain capabilities have become more valuable:

Specification Precision - The better you describe what you want, the better the output. This isn’t just “prompting”—it’s requirements engineering compressed into conversation. You need to think clearly about edge cases, constraints, and success criteria before the code exists.

Rapid Verification - Can you quickly determine if generated code is correct? This requires reading code you didn’t write, understanding patterns you didn’t choose, and spotting subtle bugs in unfamiliar implementations. Review skills matter more than ever.

System Thinking - When you can generate components quickly, integration becomes the bottleneck. Understanding how pieces fit together, managing dependencies, seeing the whole system—these architectural skills compound.

Tool Fluency - Knowing which AI tool to use when, how to structure prompts for different agents, when to intervene versus let the AI continue. There’s craft in working with these tools effectively.

Domain Knowledge - AI can generate code, but it can’t know your business domain, your users, your constraints. Deep context remains human territory. The person who understands why we’re building something guides what gets built.

What Remains Unchanged

Despite the transformation, some fundamentals persist:

Taste and Judgment - Knowing good code from bad. Recognizing when a solution is elegant versus merely functional. Understanding when to optimize and when “good enough” actually is. AI can generate many solutions; choosing the right one requires judgment.

Understanding Tradeoffs - Every technical decision involves tradeoffs. AI can explain options, but weighing them against your specific context—team capabilities, timeline, maintenance burden, performance requirements—remains human work.

Debugging Complex Systems - When something breaks in production, you still need to understand the system deeply enough to diagnose it. AI can help, but the intuition about where to look, what to try, how systems fail—that’s experience.

Communication - Explaining technical decisions to stakeholders, mentoring others, writing documentation that humans will read. The soft skills haven’t softened.

Ownership - When the system fails at 3 AM, there’s still a human on call. Accountability doesn’t delegate to AI.

The Leverage Shift

Here’s what’s genuinely new: the leverage curve has changed.

The old “10x engineer” meme suggested some developers were an order of magnitude more productive. It was exaggerated, but pointed at real variance in individual output.

Now? That leverage is accessible differently. A developer who deeply understands their domain, can specify precisely, and knows how to work with AI tools can produce output that previously required teams. Not because they’re typing faster, but because they’re directing effectively.

This cuts both ways:

• One person with AI can prototype what used to require a team

• But that person needs broader skills—you can’t just be deep in one area

• The floor rises (everyone gets AI assistance) while the ceiling gets higher (mastery compounds with AI leverage)

The question isn’t whether you can write code. It’s whether you can direct its creation, verify its correctness, and integrate it into systems that work.

So What Do We Call Ourselves?

Maybe the answer isn’t a new title. Maybe it’s accepting that “software engineer” or “developer” now encompasses a different set of activities than it did five years ago. The title persists; the job transforms.

Or maybe new terminology will emerge organically as the field matures. “Webmaster” gave way to more specific roles. Perhaps “programmer” will too.

For now, I’m comfortable with the ambiguity. The work is evolving faster than the vocabulary. What matters isn’t what we call ourselves, but whether we’re adapting to do the work effectively.

The identity crisis is real. But it might also be a feature, not a bug—a sign that we’re in genuine transition rather than incremental change.

What we call ourselves matters less than what we’re capable of doing. And on that front, the possibilities have never been larger.

Where Do We Go From Here?

The good news: we’re not starting from scratch. New practices are emerging that help us work effectively in this new paradigm. If you’re navigating this transition, here are concrete approaches worth learning:

Learn to Plan Before You Code

With AI agents, the quality of your planning directly determines the quality of your output. Planning-First Development explores how structured markdown planning documents become the foundation for focused AI-assisted development. The plan becomes the conversation starter, the context anchor, and the progress tracker.

Use Tests as Guardrails

AI agents are powerful but need constraints. Taming GenAI Agents with TDD shows how test-driven development transforms AI from a wild code generator into a disciplined development partner. Write tests first, let AI implement to pass them, verify the results. The red-green-refactor cycle works even better with AI.

Build From the Domain Out

When AI can generate boilerplate instantly, your focus shifts to what matters: the domain model. Domain-First Development advocates building pure domain logic first, independent of infrastructure. AI excels at the repetitive persistence and API layers; you focus on the business rules that require human understanding.

Capture Working Patterns

Once you solve a hard problem, don’t lose that knowledge. Example-Driven Development shows how to create working example repositories that AI agents can reference. Your past solutions become training data for future development—both for AI and for yourself.

Create Safety Nets

Working with AI means rapid iteration, which means things will sometimes go wrong. Using Git’s Staging Area as Save Points provides a lightweight mechanism for checkpointing your work before letting AI make changes. Small technique, big confidence boost.

Understand the Productivity Potential

This isn’t incremental improvement. Achieving 4x+ Productivity Gains lays out what’s actually achievable with the right tooling and mindset. The numbers are real, but they require investing in these new skills.

The programmer identity crisis is real. But crises often precede growth. The practices above aren’t just coping mechanisms—they’re the emerging craft of a new discipline. We’re figuring it out as we go, and that’s been true of this industry since the beginning.

What we call ourselves matters less than what we’re capable of doing. And on that front, the possibilities have never been larger.

Overview

This example from the k8s-vscode-remote-debug repository showcases:

• Building Elixir Phoenix applications with debug support

• Using Remote - Kubernetes extension for in-pod debugging

• Running ElixirLS inside the Kubernetes pod

• Full breakpoint debugging with proper module interpretation

What Works:

• ✅ Breakpoints in Elixir files

• ✅ Variable inspection (atoms, lists, maps, structs)

• ✅ Call stack navigation

• ✅ Step debugging (step over, step into, continue)

• ✅ Watch expressions

• ✅ Module interpretation with memory-optimized configuration

• ✅ Phoenix framework debugging

Technology Stack:

• Language: Elixir 1.18

• Framework: Phoenix

• Debugger: ElixirLS (running inside pod)

• Debug Method: Remote - Kubernetes extension (SSH to pod)

The Challenge: Why This Was Difficult

This example took significant effort to get working. Several approaches were attempted:

❌ Approaches That Didn’t Work

1. ElixirLS Remote Attach - The Erlang :int module (used for debugging) can’t interpret modules that are already loaded, making traditional remote attach impossible.

2. IEx.pry - Requires an interactive TTY, which is incompatible with containerized environments.

3. Port-forwarding to debugpy/DAP - Erlang’s distributed nature and module loading order prevented reliable debugging.

✅ The Solution: Remote - Kubernetes Extension

After extensive testing, the working solution runs ElixirLS inside the pod using VS Code’s Remote - Kubernetes extension. This:

• Avoids distributed Erlang complexity

• Runs the debugger in the same environment as the app

• Provides full VS Code integration

• Works reliably with proper module interpretation

How It Works

The debugging setup uses VS Code’s remote development capabilities:

1. SSH Connection: VS Code connects to the pod via SSH

2. In-Pod ElixirLS: ElixirLS runs inside the pod’s environment

3. Module Interpretation: Only specified modules are interpreted for debugging

4. Memory Optimization: Framework modules are excluded to reduce memory usage

This approach sidesteps the limitations of remote attach by running everything in the same Erlang VM.

Key Configuration

Dockerfile

The Dockerfile includes SSH server and development tools:

# SSH for Remote - Kubernetes
RUN apk add --no-cache openssh bash curl git

# Configure SSH
RUN mkdir -p /run/sshd && \
    ssh-keygen -A

# VS Code config embedded in image
COPY .vscode-remote /app/.vscode-remote

# Start IEx
CMD iex --name ${RELEASE_NODE} --cookie ${RELEASE_COOKIE} -S mix

See the complete Dockerfile for full configuration.

Embedded VS Code Configuration

The .vscode-remote/launch.json is embedded in the Docker image:

{
  “type”: “mix_task”,
  “name”: “mix phx.server”,
  “request”: “launch”,
  “task”: “phx.server”,
  “projectDir”: “${workspaceRoot}”,
  “debugAutoInterpretAllModules”: false,
  “debugInterpretModulesPatterns”: [
    “^Elixir\\.ElixirPhoenixWeb\\.ApiController$”
  ],
  “excludeModules”: [
    “^Elixir\\.Phoenix\\..*”,
    “^Elixir\\.Plug\\..*”,
    “^Elixir\\.Bandit\\..*”
  ],
  “requireFiles”: [
    “lib/elixir_phoenix_web/controllers/api_controller.ex”
  ]
}

Key settings:

• debugAutoInterpretAllModules: false - Memory optimization

• debugInterpretModulesPatterns - Only interpret modules you want to debug

• excludeModules - Exclude Phoenix framework modules

See the complete launch.json for all patterns.

Kubernetes Deployment

The deployment includes necessary ports and secrets:

env:
- name: RELEASE_NODE
  value: “elixir_phoenix@127.0.0.1”
- name: RELEASE_COOKIE
  valueFrom:
    secretKeyRef:
      name: elixir-erlang-cookie
      key: cookie

ports:
- containerPort: 4000
  name: http
- containerPort: 22
  name: ssh

See the complete deployment.yaml for full configuration.

Quick Start

# Set your developer namespace and registry
export NAMESPACE=dev-yourname
export REGISTRY=your-registry.azurecr.io  # Or docker.io/username, gcr.io/project, etc.

# Clone the repository
git clone https://github.com/nathanfox/k8s-vscode-remote-debug.git
cd k8s-vscode-remote-debug/examples/elixir-phoenix

# Build, push, and deploy
./manage.sh build
./manage.sh push
./manage.sh deploy

# Verify pod is ready
./manage.sh status

Debugging Walkthrough

Step 1: Install Remote - Kubernetes Extension

In VS Code:

• Open Extensions (Cmd+Shift+X / Ctrl+Shift+X)

• Search for “Remote - Kubernetes”

• Install Remote - Kubernetes by Okteto

Step 2: Connect to the Pod

Via Kubernetes Sidebar (easiest):

1. Open Kubernetes view in VS Code sidebar

2. Expand your cluster → Workloads → Pods

3. Right-click on elixir-phoenix-* pod

4. Select “Attach Visual Studio Code”

5. VS Code will reload and connect to the pod via SSH

Via Command Palette:

1. Open Command Palette (Cmd+Shift+P / Ctrl+Shift+P)

2. Run: Dev Containers: Attach to Running Kubernetes Container...

3. Select your namespace and the elixir-phoenix-* pod

4. Select container: elixir-phoenix

Step 3: Install ElixirLS in Remote Session

• VS Code will prompt to install recommended extensions

• Click “Install” for ElixirLS extension

• Wait for ElixirLS to compile and start (this may take a few minutes)

Step 4: Open App Directory

• In the remote VS Code window, open folder: /app

• ElixirLS will automatically load the embedded launch.json

Step 5: Set Breakpoints

• Open lib/elixir_phoenix_web/controllers/api_controller.ex

• Click in the gutter to set a breakpoint (e.g., line 17 in debug_test/2)

Step 6: Start Debugging

1. Open Run and Debug panel (Cmd+Shift+D / Ctrl+Shift+D)

2. Select “mix phx.server” configuration

3. Press F5 to start debugging

4. Phoenix will compile and start with debugging enabled

Step 7: Trigger the Endpoint

In your local terminal (not the remote session):

# Port-forward the application
./manage.sh port-forward

# Make a request in another terminal
curl http://localhost:4000/debug-test?count=3

Step 8: Debug

• Execution pauses at your breakpoint

• Inspect variables in Variables panel

• Use step controls:

  • F10 - Step over

  • F11 - Step into

  • F5 - Continue

Phoenix Framework Debugging

Phoenix is Elixir’s most popular web framework:

Example controller debugging:

defmodule ElixirPhoenixWeb.ApiController do
  use ElixirPhoenixWeb, :controller

  def debug_test(conn, %{”count” => count_str}) do
    count = String.to_integer(count_str)  # Breakpoint here

    items = Enum.map(1..count, fn i ->
      “Item #{i}”  # Watch items build
    end)

    json(conn, %{
      count: count,
      items: items,
      timestamp: DateTime.utc_now()
    })
  end
end

Set breakpoints to inspect:

• Phoenix connection (conn) struct

• Request parameters

• Response data

Memory Optimization

The launch.json includes critical memory optimizations:

“debugAutoInterpretAllModules”: false,
“debugInterpretModulesPatterns”: [
  “^Elixir\\.ElixirPhoenixWeb\\.ApiController$”
],
“excludeModules”: [
  “^Elixir\\.Phoenix\\..*”,
  “^Elixir\\.Plug\\..*”
]

Why this matters:

• Interpreting all modules causes excessive memory usage

• Phoenix framework has many modules

• Only interpret the specific modules you’re debugging

VS Code Extensions

Required for debugging:

• Remote - Kubernetes (okteto.remote-kubernetes) - Connects VS Code to pod

• ElixirLS (jakebecker.elixir-ls) - Elixir language support and debugger

• Kubernetes (ms-kubernetes-tools.vscode-kubernetes-tools) - Cluster navigation

The Kubernetes extension helps you find and attach to pods, while Remote - Kubernetes handles the SSH connection.

Troubleshooting

Can’t Connect to Pod

1. Verify pod is running:

./manage.sh status

1. Check SSH is accessible:

kubectl exec -n $NAMESPACE -l app=elixir-phoenix -- ssh -V

1. Verify Remote - Kubernetes extension is installed

ElixirLS Won’t Start

1. Check Elixir/Erlang versions in pod:

kubectl exec -n $NAMESPACE -l app=elixir-phoenix -- elixir --version

1. Rebuild if needed:

./manage.sh build
./manage.sh push
./manage.sh restart

Breakpoints Not Hitting

1. Verify module is in debugInterpretModulesPatterns:

   • Check .vscode-remote/launch.json in the pod

   • Add your module pattern if missing

2. Check module is compiled:

   • In the debug terminal, verify Phoenix compiled successfully

3. Restart debug session:

   • Stop debugger (Shift+F5)

   • Start again (F5)

High Memory Usage

If the pod runs out of memory:

1. Reduce interpreted modules:

   • Be more specific in debugInterpretModulesPatterns

   • Add more patterns to excludeModules

2. Increase pod memory limit in deployment.yaml

Example-Driven Development with AI Agents

This repository demonstrates Example-Driven Development, designed to work with AI coding assistants like Claude Code.

For more on this pattern, see Example-Driven Development Using AI Agent Claude Code.

Example AI prompt:

“Using the k8s-vscode-remote-debug repository’s Elixir Phoenix example, add remote debugging support to my Phoenix application running in Kubernetes using the Remote - Kubernetes extension.”

The AI can generate the appropriate Dockerfile with SSH setup, embedded VS Code configuration, and deployment manifests based on the working example.

Next Steps

For complete details including:

• Full troubleshooting guide

• Alternative debugging approaches

• Manual in-pod debugging method

• Implementation planning notes

See the complete README in the repository.

The repository includes examples for 8 languages/frameworks, each demonstrating the unique aspects of debugging that language in Kubernetes.

Overview

This example from the k8s-vscode-remote-debug repository showcases:

• Building Rust applications with structured tracing

• Deploying to Kubernetes with comprehensive logging

• Using the tracing crate for observability

• Debugging async Rust code in production environments

What Works:

• ✅ Structured logging with multiple levels (trace, debug, info, warn, error)

• ✅ Function instrumentation with automatic argument logging

• ✅ Async code debugging via tracing spans

• ✅ Production-ready observability

• ✅ Low overhead when disabled

• ✅ Complex type logging with Debug trait

Technology Stack:

• Language: Rust 1.83

• Framework: Actix-web 4.11

• Debugging Method: Structured logging (tracing crate)

• Runtime: Tokio async runtime

Why Tracing Instead of Traditional Debugging?

TLDR: LLDB breakpoints don’t work reliably with async Rust code in Kubernetes.

Traditional debuggers like LLDB can attach to Rust processes and resolve breakpoints, but breakpoints never trigger in async functions running on Tokio’s worker threads. This is a fundamental limitation of current debugging tools with Rust’s async runtime model.

Instead, the Rust ecosystem has embraced structured tracing as the primary debugging and observability approach for async applications.

How It Works

The debugging setup uses the tracing crate ecosystem:

1. Tracing Subscriber: Initialize logging backend in main()

2. Instrumentation: Use #[instrument] macro on functions

3. Structured Logs: Log events with structured data

4. Spans: Track async execution flow with tracing spans

This approach provides observability that works reliably with async code and scales to production environments.

Key Configuration

Application Code (main.rs)

Initialize tracing in your application:

use tracing::{info, debug, instrument};
use tracing_subscriber;

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Initialize tracing with debug level
    tracing_subscriber::fmt()
        .with_env_filter(”debug”)
        .init();

    info!(”Starting Rust Actix-web server on 0.0.0.0:8080”);
    // ... rest of setup
}

Instrumented Functions

The #[instrument] macro automatically logs function entry/exit with arguments:

#[instrument]
async fn debug_test(query: web::Query<DebugTestQuery>) -> Result<HttpResponse> {
    info!(”Debug test called with count={}”, query.count);

    let mut items = Vec::new();
    for i in 0..query.count {
        debug!(”Processing item {}/{}”, i + 1, query.count);
        items.push(format!(”Item {}”, i + 1));
        thread::sleep(StdDuration::from_millis(10));
    }

    info!(”Debug test completed, returning {} items”, items.len());
    Ok(HttpResponse::Ok().json(response))
}

See the complete main.rs for the full application code.

Cargo.toml Dependencies

Add tracing dependencies:

[dependencies]
tracing = “0.1”
tracing-subscriber = { version = “0.3”, features = [”env-filter”] }

See the complete Cargo.toml for all dependencies.

Dockerfile

The Dockerfile uses a multi-stage build with Rust-specific caching:

# Builder stage
FROM rust:1.83 AS builder
WORKDIR /build

# Cache dependencies
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo “fn main() {}” > src/main.rs
RUN cargo build

# Copy source and rebuild
COPY src ./src
RUN touch src/main.rs  # Force recompilation (Rust-specific cache workaround)
RUN cargo build

# Runtime stage
FROM debian:bookworm-slim
COPY --from=builder /build/target/debug/rust-actix /usr/local/bin/
EXPOSE 8080
CMD [”rust-actix”]

Important: The touch src/main.rs is critical - it forces Cargo to recompile and avoid stale cache artifacts. See the complete Dockerfile for details.

Quick Start

# Set your developer namespace and registry
export NAMESPACE=dev-yourname
export REGISTRY=your-registry.azurecr.io  # Or docker.io/username, gcr.io/project, etc.

# Clone the repository
git clone https://github.com/nathanfox/k8s-vscode-remote-debug.git
cd k8s-vscode-remote-debug/examples/rust-actix

# Build, push, and deploy
./manage.sh build
./manage.sh push
./manage.sh deploy

# Verify pod is ready
./manage.sh status

Debugging Walkthrough

1. Port-forward the application (in a terminal):

./manage.sh port-forward

1. Make requests to trigger tracing:

curl http://localhost:8080/health
curl http://localhost:8080/debug-test?count=5
curl http://localhost:8080/weatherforecast

1. View structured logs:

./manage.sh logs

1. Follow logs in real-time:

./manage.sh logs -f

Example Output

2025-09-28T17:44:34.582173Z  INFO rust_actix: Starting Rust Actix-web server on 0.0.0.0:8080
2025-09-28T17:44:34.582361Z  INFO actix_server::builder: starting 1 workers
2025-09-28T17:45:12.123456Z  INFO rust_actix::debug_test: Debug test called with count=5
2025-09-28T17:45:12.123567Z DEBUG rust_actix::debug_test: Processing item 1/5
2025-09-28T17:45:12.133789Z DEBUG rust_actix::debug_test: Processing item 2/5
2025-09-28T17:45:12.143890Z DEBUG rust_actix::debug_test: Processing item 3/5
2025-09-28T17:45:12.153991Z DEBUG rust_actix::debug_test: Processing item 4/5
2025-09-28T17:45:12.164092Z DEBUG rust_actix::debug_test: Processing item 5/5
2025-09-28T17:45:12.164193Z  INFO rust_actix::debug_test: Debug test completed, returning 5 items

Tracing Features

Instrumentation Macro

The #[instrument] macro provides automatic function tracing:

#[instrument]
async fn my_handler(id: u32, name: String) -> Result<HttpResponse> {
    // Automatically logs function entry with: id=42, name=”example”
    // Automatically logs function exit
}

Structured Fields

Log structured data with key-value pairs:

info!(user_id = %user.id, action = “login”, “User logged in”);
debug!(count = items.len(), “Processing items”);

Tracing Levels

• trace!() - Very detailed, usually disabled

• debug!() - Debug information

• info!() - General information

• warn!() - Warning messages

• error!() - Error conditions

Async Spans

Track async execution flow:

use tracing::instrument;

#[instrument]
async fn process_request(req: Request) -> Response {
    let span = tracing::info_span!(”database_query”);
    let result = async {
        // Database operations traced under this span
    }.instrument(span).await;

    result
}

Benefits of Tracing Approach

Production Ready:

• Works reliably in production environments

• Can be enabled/disabled via environment variables

• Low overhead when disabled

Async Compatible:

• Designed for async Rust from the ground up

• Tracks execution across await points

• Works with Tokio, async-std, etc.

Structured Data:

• Log complex types with Debug trait

• Machine-parseable output

• Easy to integrate with log aggregation systems

Zero Cost:

• Compiled out in release builds without env filter

• No runtime overhead when disabled

Actix-web Framework

Actix-web is a powerful, pragmatic Rust web framework:

• Built on Tokio async runtime

• Type-safe request routing

• Middleware support

• WebSocket support

• HTTP/2 support

Example handler:

#[get(”/debug-test”)]
#[instrument]
async fn debug_test(query: web::Query<DebugTestQuery>) -> Result<HttpResponse> {
    info!(”Processing request with count={}”, query.count);
    // Handler logic with tracing
    Ok(HttpResponse::Ok().json(response))
}

Troubleshooting

No Logs Appearing

1. Check tracing is initialized:

tracing_subscriber::fmt()
    .with_env_filter(”debug”)
    .init();

1. Verify log level:

   • Set RUST_LOG=debug environment variable

   • Or use with_env_filter(”debug”) in code

2. Check pod logs:

./manage.sh logs --tail 100

Binary Exits Immediately

Problem: Container exits with code 0 immediately after starting

Solution: This is usually a Cargo cache issue. The Dockerfile includes RUN touch src/main.rs to force recompilation. If you still see this:

# Rebuild from scratch
./manage.sh build
./manage.sh push
./manage.sh restart

Missing Tracing Output

1. Ensure functions are instrumented:

#[instrument]  // Add this
async fn my_function() { }

1. Check log statements exist:

info!(”Important event”);
debug!(”Debug details”);

Example-Driven Development with AI Agents

This repository demonstrates Example-Driven Development, designed to work with AI coding assistants like Claude Code.

For more on this pattern, see Example-Driven Development Using AI Agent Claude Code.

Example AI prompt:

“Using the k8s-vscode-remote-debug repository’s Rust Actix example, add structured tracing to my Actix-web application running in Kubernetes.”

The AI can generate the appropriate tracing setup, instrumentation, and deployment configuration based on the working example.

Next Steps

For complete details including:

• Full troubleshooting guide

• LLDB investigation details

• Advanced tracing patterns

• Production deployment considerations

See the complete README in the repository.

The repository includes examples for 8 languages/frameworks, each demonstrating the unique aspects of debugging that language in Kubernetes.