I Built One Project in a Year and Another in Two Months: What Changed With AI-Assisted Development

AlbumMap — Sat, 12 Sep 2026 02:41:41 +0000

EngHub took me roughly a year to develop, with GPT-5 being part of my development workflow.

My newer project, AlbumMap, took about two months to build while I was using GPT-5.5.

That difference was difficult for me to ignore.

The newer model felt noticeably more efficient during my own development process. I could move from an idea to an implementation faster, iterate on problems more quickly, and spend less time getting stuck on smaller technical issues.

But I do not think the right conclusion is:

GPT-5.5 made me six times faster.

These were two different projects, built at different times, with different requirements. They were not controlled experiments.

What the experience did show me was something more useful: AI coding tools are becoming much better at reducing the distance between an idea and a working implementation.

A Shorter Build Is an Observation, Not a Benchmark

There are many factors that affect how long a software project takes.

Scope matters. Experience matters. The technologies you already know matter. The amount of time you can dedicate to the project matters.

Even your definition of “finished” can completely change the timeline.

By the time I started AlbumMap, I also had knowledge from previous projects that I did not have when I started EngHub.

So I cannot attribute the difference in development time entirely to GPT-5.5.

What I can say is that working with the newer model felt significantly more efficient in my own development workflow.

That made me think about a more interesting question:

How should we evaluate AI coding assistants when we are using them to build real products?

Generated Code Is Not the Same as a Working Feature

One thing I have learned is that evaluating an AI coding assistant based only on the code it generates can be misleading.

A piece of code can look clean.

The UI can render correctly.

Buttons can respond.

And the feature can still be wrong.

AlbumMap is a map-based video platform that lets people combine photos, videos, messages, and locations into a visual story.

Users can also invite other people to contribute media, review those contributions, organize them, and generate the final video.

That creates a good example of why I think end-to-end behaviour matters more than generated code quality alone.

Imagine an organizer receives two video contributions.

They approve the first contribution and reject the second.

At the UI level, everything might appear to work perfectly:

The Approve button changes state.
The Reject button changes state.
Both actions are saved.
The screen looks correct.

But the real acceptance test is different.

When the final video is generated, does the approved contribution appear?

Is the rejected contribution actually excluded?

That is the behaviour the user cares about.

Test the Workflow, Not Just the Screen

Now make the scenario slightly more complicated.

The organizer has five contributions.

They approve three.

Then they change their order.

They refresh the browser.

They return to the project later.

Finally, they generate the video.

A useful test would check:

Did the approval status survive the refresh?
Did the selected order remain unchanged?
Are rejected contributions still excluded?
Does the preview match the final export?
Does the exported video preserve the same sequence the organizer selected?

These are simple questions, but they test the actual product rather than the appearance of the implementation.

That distinction becomes even more important when working with AI-generated code.

AI can produce an implementation extremely quickly.

But speed increases the importance of having a clear way to determine whether the implementation is actually correct.

Define Success Before Asking AI to Implement Something

I have also found that the quality of the result improves significantly when the expected behaviour is defined before asking an AI coding assistant to build the feature.

For example, instead of writing:

“Make the contribution editor work.”

A much better specification would be:

“Build the contribution review flow so that only approved contributions appear in the preview and final export. Preserve the user’s selected order after refreshing the page. If saving fails, show a clear error and do not display the change as successfully saved.”

Now there are measurable conditions.

You can test them.

The AI can reason around them.

And if the implementation fails, it is much easier to identify where the problem is.

This has become one of the biggest changes in how I work with AI-assisted development.

I try to spend more time describing what must be true when the feature is finished rather than simply describing what code I want generated.

AI Helped Me Iterate Faster, But It Did Not Replace Product Decisions

AlbumMap gave me a useful environment for testing this approach because the product involves several connected systems.

Users can collect media from different people, associate memories with locations, arrange content, change how the map appears, and eventually turn everything into a video.

For example, someone creating a group birthday video might collect messages and videos from friends or family living in different cities or countries.

The interesting part is not simply uploading those files.

The system has to preserve the relationship between:

The person
Their message
Their media
Their location
Their order in the story
What eventually appears in the generated video

An AI coding assistant can help implement those systems faster.

But it still does not decide what the correct product behaviour should be.

That remains the developer’s responsibility.

Faster Implementation Changes Where the Bottleneck Is

This may be the biggest difference I noticed between my earlier project and building AlbumMap.

As coding assistance improves, writing the implementation is becoming less of the bottleneck.

The harder questions increasingly become:

What exactly should this feature do?

What happens when something fails?

What should persist?

What does the user expect to happen next?

How do I know the implementation is actually correct?

Those are product and engineering questions rather than code-generation questions.

And faster code generation makes them more important, not less.

If an assistant can generate a feature in minutes, it is very easy to move quickly in the wrong direction.

What the One-Year-Versus-Two-Month Difference Taught Me

The contrast between these two projects made the improvement in AI-assisted development very noticeable to me.

EngHub took roughly a year.

AlbumMap took roughly two months.

Again, I would not use those numbers as a benchmark for comparing GPT-5 and GPT-5.5.

There are too many other variables involved.

But from my perspective as the person building both projects, the development experience has changed substantially.

I am spending less time fighting through implementation details and more time thinking about behaviour, product decisions, edge cases, and how the complete system should work.

That is where I currently see the biggest value of modern AI coding assistants.

They do not remove the developer from the process.

They reduce the distance between:

idea → implementation → testing → iteration

And when that distance becomes shorter, you can test more ideas, reject bad ones earlier, and spend more time improving the parts of the product that actually matter to users.

For me, that is much more interesting than simply measuring how many lines of code an AI model can generate.

DEV Community: AlbumMap