Project 1: Harbour Vessel (2023) — The Failure

Harbour Vessel is a platform for managing container shipping logistics — tracking containers across ocean, rail, and truck. Our client needed a web dashboard to visualize cargo movements and compliance. 6-week timeline. Tight, but doable.

Three weeks in, the team was stuck. The schema was complex. Shipping containers have dozens of state transitions, regulatory requirements, edge cases. The dashboard had to handle real-time updates, historical replay, compliance reporting. The spec was solid, but the implementation felt like pushing uphill.

We decided to try something new: use AI to help write the UI layer faster. Generate components, write queries, bootstrap boilerplate. Save time. We used the latest model at the time (early 2023).

It was a disaster.

The AI generated code that looked right but didn't work. Components didn't compose. Queries were inefficient. What we got was syntactically correct but semantically wrong — code that compiled but didn't solve the actual problem. We had to rewrite most of it anyway. The time saved in generation was lost in debugging and rework.

Why did it fail? Because the problem wasn't "write code that compiles." The problem was "write code that correctly represents complex shipping logic and responds to real-time updates." The AI couldn't see the constraint — it just saw "write a React component" and did the minimum thing that matched that description.

Project 2: Recall Management System (2024) — The Success

A year later, we took on a different project: a recall management system for a major brand. Track product recalls across distribution channels, notify affected customers, manage returns. Government-regulated.

The spec was clear: intake form for a new recall, propagate to affected batches, generate notification templates, track response. Standard business logic. No tricky state machines. No real-time complexity.

We estimated 4 weeks. The client asked if we could do it faster. We said no — 4 weeks is realistic. Then we thought: what if we use AI to handle the boilerplate layer? There's a lot of straightforward code here: CRUD operations, form handling, email template generation. Stuff where "write a React form that submits to an API" is actually what we want.

We tried it. Used AI to generate the initial structure — form components, API handlers, notification templates. This time it worked. Not perfect, but 80% there. We reviewed it, tweaked the 20%, and shipped. We hit the deadline 5 days early.

The difference: the problem was well-defined. The constraints were explicit. There were no gotchas. "Write a form that submits to an API" is actually the complete specification, not a simplification of a more complex problem underneath.

What Actually Changed Between 2023 and 2024

It wasn't the model. We used better models in 2024, but that's not why it worked.

It was the problem definition.

In 2023, we fed AI a complex spec (shipping logic, state transitions, real-time updates) and asked it to write components. It wrote generic components. We expected it to infer the constraints and bake them into the code. It couldn't.

In 2024, we gave AI a straightforward spec (forms, CRUD, notifications) and asked it to write boilerplate. It wrote boilerplate. We didn't expect it to understand the deep logic — we just wanted faster scaffolding. It delivered.

The lesson: AI is useful for problems where the specification IS the solution. Not problems where the specification is an approximation of something more complex.

The Pattern We Found

After two years of experimenting, we can predict whether AI will help or hurt:

AI works well when:

• The spec is complete and unambiguous. "Build a form with these fields" is clear. "Build a shipping dashboard" is not.
• The task is boilerplate-heavy. CRUD operations, email templates, test fixtures, data transformations — things where the pattern is standardized.
• Correctness is verifiable through testing. If tests pass, the code is probably right. In shipping logic, tests can miss edge cases.
• The solution is truly independent. A recall notification form doesn't depend on subtle interactions with other parts of the system. The Harbour Vessel dashboard depended on every piece being correct.

AI fails when:

• The spec is an approximation of a complex domain. The client says "shipping dashboard" but means "visualize state transitions while respecting regulatory constraints and handling edge cases."
• Correctness is hard to verify. The code runs, but does it capture the business logic? You might not know until production.
• The problem requires deep context. Why does this state transition exist? What edge case did it solve? AI can't answer that.
• There are implicit constraints. "Fast" doesn't mean "under 100ms" — it means "match user expectations from similar systems." AI doesn't know what those expectations are.

How to Know Before You Start

Before you commit to using AI for a project, ask these questions:

1. Can you test it thoroughly? If the answer is "yes," AI-generated code is probably safe. Automation systems, form handling, data pipelines — you can test the hell out of these and know if they're correct. Shipping logic, safety-critical features — hard to test exhaustively.

2. Is the problem well-scoped? If you can describe it in one sentence without caveats, AI can probably help. "Generate email templates for recall notifications" is one sentence. "Build a dashboard for shipping" needs paragraphs to be complete.

3. Is it boilerplate or logic? Boilerplate = AI wins. Logic = human review essential.

4. What's the cost of failure? If an email template is 90% right, you tweak it. If shipping state logic is 90% right, you might miss edge cases in production.

The Harbour Vessel project failed not because the team was inexperienced with AI, but because we tried to solve a complex logic problem with a tool designed for pattern matching. The Recall Management system succeeded because we asked the tool to do what it actually does well: generate boilerplate from specifications.