Janarayson

From one GPT report to building everything with agents

Retrospective8 min read

Three years ago our first AI feature was a paragraph of GPT-3.5 commentary in a MailerTrack report. Today I'm the only full-time engineer at FinLit and the agents write the code. What happened in between.

In September 2023, we wired GPT-3.5 into a MailerTrack report. It read three small tables of promotional data and wrote a headline and a paragraph. That was the first AI feature we shipped, and it never made it out of beta.

Three years later, I’m the only full-time engineer at FinLit, and I haven’t written a line of code since early this year. The agents write it.

When autocomplete felt like magic

The first AI tool I used regularly for development was GitHub Copilot, back at Intrack.

The autocomplete felt like magic. You’d start writing a function, and Copilot would suggest the next few lines, sometimes the whole thing. Press Tab and there it was.

Shia LaBeouf saying magic

It was useful, but you were still writing most of the code yourself.

For anything more complicated, I’d copy a function or a module into ChatGPT, explain what I wanted, wait for the answer, then paste the code back into my editor.

The model couldn’t see the rest of the project. It didn’t know how the other modules worked or what was already available in the codebase. You had to provide all that context yourself, one conversation at a time.

A boy at a computer pressing Ctrl and C

Looking back, it was terribly inefficient. But at the time, being able to ask a model to write or fix a function was something new, and I was quite happy working that way.

Putting GPT in front of other people

Around the same time, we started experimenting with putting AI into our products.

AI PromoPulse was the first. A supplier using MailerTrack could select a product category and a date range, and GPT-3.5 would look at three tables of promotional data and write a short summary.

We spent quite a bit of time refining the prompt, but the analysis was hit and miss. Sometimes it picked out something useful. Other times it produced a bland paragraph or made observations the data didn’t support.

We never felt comfortable charging clients for analysis that wasn’t consistently reliable, so it stayed in beta and was eventually retired.

The next experiments weren’t about code or data analysis.

In January 2024, I used ChatGPT and Synthesia to make an AI avatar present four minutes of my quarterly Tech Bites town hall. A month later, we made another video for the full-year Promo Pulse report.

People were impressed by how real the presenter looked. But the idea of turning client reports into videos didn’t go anywhere. The effort and cost didn’t make sense.

I did use Synthesia for another town hall that July, this time with two presenters.

Part of the reason for these experiments was to encourage AI adoption at Intrack. I’d been talking about how we could use AI in our work, and I thought showing people something we’d actually made would help.

Adoption was slow.

A skeleton sitting and waiting patiently

When Claude could see the repository

In 2025, Intrack subscribed to Claude, and I started using it for development.

I can’t remember exactly which model I started with. Claude 3.7 Sonnet came out in February, followed by Claude 4 in May, so it would have been around that period.

What mattered more was Claude’s GitHub integration, which became available across all its plans in February.

For the first time, I could connect a Claude project to a repository and ask questions about the code without copying everything into the chat myself.

It was a big improvement, although the workflow was still fairly manual. I’d ask Claude to look at particular files, discuss the changes, then take the result back into my editor.

Then agent mode arrived in GitHub Copilot, rolling out to everyone using VS Code in April 2025.

That was a different experience. The agent could inspect the codebase, make changes across files, run commands and respond to errors. Instead of asking a model for code to paste, I was giving it work to do inside the project.

Starting again with MoneyMama

I joined FinLit in June 2025 to build MoneyMama, going from a six-person engineering team at Intrack to working mostly on my own, with some part-time development help.

We subscribed to Claude there too, and I started trying just about every coding assistant that came along.

Copilot, ChatGPT, Cursor and Claude were the early ones. Then came Kiro, Qoder and Antigravity through the second half of the year.

I wasn’t particularly loyal to any of them. I wanted to see what each could do and whether it made building MoneyMama easier.

One thing that stuck was spec-driven development.

Kiro and Antigravity put a lot of emphasis on writing the requirements, design and implementation tasks before letting the agent start coding. Claude’s plan mode gave me a similar way to work: have the agent work out an approach, review it, then let it make the changes.

I found that building features this way produced far fewer errors than simply telling an agent what I wanted and letting it start writing code.

Somewhere around this period, the whole experience started to change.

I can’t point to a particular day. It was more that the tools became good enough to understand how the different parts of a codebase fitted together. And with MCP, they could work with things outside the code too, including the database.

I no longer had to explain every file or keep copying snippets between a chat window and my editor.

Tim and Eric mind blown, with the universe behind

I kept trying different tools, but eventually settled on Claude Code in VS Code.

Its native VS Code extension arrived in September 2025, and that was when I started using it for almost everything.

I’d tried the terminal experience, but never really liked it. I wanted to stay in a familiar IDE, see the files change, review the diffs and make corrections where needed.

Claude Code gave me that.

What we’ve built since

Over the past year, with a part-time developer helping on parts of MoneyMama, I’ve used agents to build quite a bit.

We started with Mama on WhatsApp, then built the iOS and Android app. Around those came the portals for our internal team and financial planners.

We also built a simulator that turns scripted conversations into reels and carousels, along with internal tools for the content and sales teams: analytics, scrapers, transcribers and a CRM that our account managers can use directly through Claude over MCP.

All of this would have been a very different undertaking a few years ago, especially with such a small engineering team.

But I don’t consider what I’m doing vibe coding.

I still design the architecture, work through the implementation plans, review the changes and make sure the work is backed by tests. The agents write the code, but I’m responsible for what goes into the product.

The strange part is that I haven’t written a single line of code myself since early this year.

And I can feel it.

I used to spend much of my day working through code, figuring out how something should be implemented and fixing things by hand. Now I spend more time describing what needs to be built, reviewing what an agent has produced and deciding whether it’s good enough.

It’s a different set of skills, and I can tell that the old ones are getting rusty.

Kermit the Frog saying maybe we're a little rusty

Building is one thing. Maintaining is another.

Having agents write the code doesn’t mean I can leave the codebases alone.

They still need maintaining, and that’s where I’ve become more particular about how I use Claude.

Without the right instructions and skills, it can produce a lot of slop. Redundant functions, duplicated logic, comments that explain the obvious and implementations that are more complicated than they need to be.

Those things accumulate, especially when the agent keeps adding code without understanding what should be reused or removed.

I’ve been putting more effort into giving Claude the right skills and conventions, not just for implementing features but for keeping the existing code in good shape.

What the agents can’t replace

There’s still one thing I miss from working at Intrack.

People.

The first few weeks at FinLit were lonely. I was used to having other engineers around, people I could talk things through with, ask questions or just bounce ideas off.

Now I have Claude available whenever I need it, and I can discuss architecture, debug a problem or work through an implementation without another developer beside me.

But it’s not the same as working with a team.

For all the things these agents can do, nothing beats having another human to talk to.