AI-Assisted Coding: What Building Scheduled Smiles Is Teaching Me

The first article in a series about my experiences with AI-driven development.

The more implementation AI can take on, the more attention can shift to the decisions around it: what to build, how the pieces should fit together, and whether the result is ready for users. That has been the biggest surprise of building Scheduled Smiles. My experience managing engineers has become more useful as I delegate more of the coding.

Over the past year and a half, working with these tools has changed how I think about software development. This series explores the ideas emerging from that experience, with real examples of what has worked, what has been frustrating, and what remains uncertain. Whether you build software, lead an engineering team, or commission development for your business, the question is increasingly relevant: what does good engineering look like when AI does much of the implementation?

Scheduled Smiles: the case study behind the ideas

Scheduled Smiles helps busy people remember birthdays, anniversaries, and other occasions, and follow through with a thoughtful gesture for friends and family. Alongside reminders, its Auto Send features let you personalize and schedule e-cards, mailed greeting cards, or flowers ahead of time, putting the sending on autopilot. A reminder before anything goes out gives you a chance to review, edit, or cancel. Small gifts are planned, and integrations with AI assistants such as ChatGPT and Claude are in development to make arranging these gestures as easy as a conversation. The idea is simple: help someone feel remembered, even when life gets busy.

Development began in December 2025, using Cursor from day one. Scheduled Smiles is a project I work on when time allows, alongside my full-time work at Trificient Digital, my technology strategy consulting business. The roughly ten months since the first commit therefore represent elapsed time, not ten months of full-time development. A repository inventory dated 1 October 2026 gives a sense of what sits behind that simple premise:

• 67 pages and more than 250 components support the customer experience and administration of the product.

• 13 external service integrations connect capabilities such as payments, flower delivery, mailed cards, email, and customer sign-in.

• About 5,400 automated test definitions span the backend, frontend, browser journeys, and scripts, alongside roughly 180,000 lines of test code.

• More than 350,000 lines of product source cover the web application, APIs, database migrations, and background services, excluding generated database designer and snapshot files.*

The interesting part is the range of engineering work those figures represent. A thoughtful gesture for the recipient depends on many pieces working together: the right occasion, the right message, a payment, a vendor order, and a way to investigate when something goes wrong. That makes Scheduled Smiles a useful setting for exploring architecture, testing, and operations as well as AI-generated code.

Source and test-code figures count physical lines, including comments and blank lines. Test figures count definitions in the repository, not a verified test run. These are measures of scope, not productivity or quality.

Scheduled Smiles is a solo project. The examples here come from directing AI across the user interface, backend, and infrastructure. Applying these ideas within a development team brings additional coordination challenges; future articles will distinguish firsthand experience from other people's accounts and research.

Delegation makes communication an engineering skill

Useful delegation starts with context. What should the feature achieve? Which business rules matter? What needs clarification before implementation begins?

With Cursor, that often starts as a dictated brain dump, followed by questions one at a time. A plan turns the discussion into something concrete enough to review. Tradeoffs can then be examined and the approach refined before code is written.

The process feels familiar from engineering management: explain the outcome, invite questions, and evaluate whether the proposed work addresses the actual need. Those skills transfer well to AI-assisted coding. Accountability stays with the person directing and releasing the work; the tool does not carry an engineer's professional responsibility.

One small habit has been particularly useful. Once a plan looks largely right, I ask:

Please critique this plan.

Leaving that request open-ended gives Cursor room to raise concerns beyond the questions already discussed. A plan that satisfies the original request may still contain assumptions worth challenging.

The Cardly integration for mailed cards provides an example. Its revised plan records a risk surfaced during review: copying an existing catalog-sync pattern could cause an empty vendor response to mark the whole mailed-card catalog inactive. The resulting implementation added a minimum-item check that stops the sync before deactivation when too few items come back. This was a potential defect identified during planning.

An established pattern can carry an established problem. Asking for another look helped expose that risk before implementation, while reviewing the findings and deciding what to change remained a human judgment.

A plan also leaves room for iteration. Running the application locally and going through it as a user often reveals interactions that need refinement, even when the underlying functionality works. Clear direction and feedback matter throughout delivery.

Engineering practices behind AI-assisted coding

Delegation becomes more useful when expectations are explicit and results can be checked.

Scheduled Smiles had documentation, automated testing, and CI/CD from the beginning. Changes go through automated checks and my pull-request approval. Unit and integration tests came first, with UI tests added later as the product developed.

Documentation is especially useful when it explains business rules and why the application behaves a certain way. Keeping that context in the repository makes it available to Cursor as the software changes. Tests can express those expectations too, although their value depends on what they actually check.

Reuse is another example. E-cards, flowers, and mailed cards behave differently, but their dialogs should feel consistent. Shared components help preserve that consistency. When the same expectation needs repeating, a project rule can make it explicit for subsequent work. These rules develop alongside the product as recurring problems reveal what needs clearer direction.

Those practices also shape how much to delegate. My trust in Cursor has grown, and the time I spend reviewing generated code has decreased. That trust draws on project rules, automated checks, exploratory testing, and asking for clearer explanations when the reasoning is unclear. I am still working out whether the balance is always right.

AI can make the same mistaken assumption in both the implementation and its tests. Passing tests do not settle every question, and a convincing explanation is not proof. Exploring the working product and evaluating test coverage remain important engineering work. QA expertise becomes valuable in deciding which behaviors need evidence and whether the tests supply it.

Better evidence can matter more than another proposed fix

A recent passkey problem showed how much the direction of an investigation matters.

Saving a passkey failed when LastPass was installed. Cursor and I were struggling to find the cause, and the investigation was frustrating. Without expertise in that particular interaction, I asked Cursor to tighten the logging so we could see more precisely what was happening.

That exposed the cause: application code intended to hide autofill icons was also deleting a shared container LastPass needed to display its passkey dialog. The fix narrowed that cleanup behavior, and regression tests were added to protect the container.

The useful intervention was recognizing that we lacked enough information. Better evidence gave Cursor what it needed to investigate and implement the fix. Choosing how to investigate, and recognizing when the approach needs to change, is an engineering decision in its own right.

Where these ideas lead

These experiences suggest that broad engineering knowledge becomes more valuable as more implementation can be delegated. Architecture, communication, test design, and judgment all shape the quality of what an AI tool produces.

The next articles will explore those ideas in more depth:

• Planning and critique: how discussion, questions, and a second look improve an approach before implementation.

• Architecture and reuse: why understanding the whole system matters when AI can write across the entire application.

• Testing and debugging: how automated checks, exploratory testing, and operational evidence help evaluate the result.

• Leadership and delivery: how management skills transfer to AI-assisted engineering, including examples from client work at Trificient Digital.

Some articles will be technical. Others will examine changes in roles, habits, and judgment. Helping organizations develop the processes and confidence to use AI-assisted engineering well is also a direction I want to pursue through Trificient Digital. Translating these practices from solo development to teams is an important part of that exploration.

Faster implementation gives engineers more scope to build. It also makes decisions about direction, architecture, evidence, and release readiness more consequential. That is the thread connecting these stories, and the question worth discussing:

As AI writes more of the code, which engineering decisions deserve more of our attention?