Skip to main content

Command Palette

Search for a command to run...

Reflecting on my AI adoption timeline

My journey from tab completion to... whatever we call this now.

Updated
13 min read
Reflecting on my AI adoption timeline

While talking to a friend recently about how we’re using AI at work, I realised that I couldn’t remember the last time I meaningfully hand-coded something.

This was a pretty profound realisation. I’ve basically become one of those people who don’t write code by hand anymore. And yet, there I was, a mere 12 months ago, when AI was going through one of it’s first “it’s over” hype phase, 1000% sure that “agentic coding” was BS and I’d never be shipping with it.

Oops 😅.

The rate-of-change has been wild to say the least. And it has freaked me out enough to want to write this post. I want to capture this moment in time before I forget how I got here in the first place. A little historical artefact. I don’t know interesting or useful this will be to anyone, but at the least, it could be fun to share this with my future kids one day.

(Skip to the end to see my current setup)

Pre-June 2025

My first “AI coding” experience was a common one: GitHub Copilot; I bought the GitHub Copilot annual plan in November 2023. Purely tab completion, it was freaking magical. Type some code, and it would auto-complete the function for you. The group chats I was in at the time were hysterical.

At some point, the whole “agentic” phenomena was born. I remember there was some early open source efforts experimenting with agent loops, but none of them meaningfully took off. I do remember the Devin hype, and being as skeptical as everyone about it. In any case, I hadn’t touched any “agentic” tool up until this point.

Around May 2025 or so, I installed Cursor.

Cursor and Windsurf had already been out for a while, but I’d heard so many mixed reviews that I never bothered to try either. I was still a big AI skeptic at this point. I was working in a legacy codebase at the time, a classic mishmash of half-completed tech debt projects sprawling many repositories, and with no type safety or no tests, it was truly a minefield. I thought there was just no way AI would ever be good enough, have enough context, to be helpful in that environment.

Anyway back to Cursor. Cursor was “the shiz” at this time. All over the Twitter timeline, it had cemented itself as the brand and product in the AI coding space. By now it had some agentic capability via its famous sidebar (it might have had it from the start, I don’t quite remember). I was finally compelled enough to install and take it for a spin on something real.

At the time I was maintaining a popular OSS project, linkedin-api, an unofficial Python wrapper for the LinkedIn API. As a little growth hack idea, I wanted to spin up a bunch of how-to guides for using the library: “How to programatically post on LinkedIn with Python”, that kind of thing.

The perfect test task for Cursor, I thought!

I told the Cursor agent something like, “look at my docs and come up with 5 simple and popular usecases you think would be good candidates for how-to-style articles". And then, “Ok, now write the help guide for each one”.

I remember it being a bit fiddly, but fundamentally it got the job done.

This was probably my “oh sh*t” moment. That it could take a slightly abstract problem, break up into multiple steps, do basic edits across files, etc. But most importantly: actually be useful, and actually save me time, locally on my machine, in my editor.

I purchased the Cursor $20/month plan that day.

I was on Twitter a lot more, frantically trying to keep up with the AI discourse from my little beachside home in Australia. For various reasons, I felt like I wasn’t in the right job to fully take advantage of these tools, and I remember feeling like, “if I leave this too long, I feel like this isn’t gonna be good for me”.

So, on June 3rd I started a new job as a Founding Engineer for a startup. My real AI journey begins here…

June 3, 2025

Looking back, this was maybe the most opportune time to take a founding engineer role. A role whose whole mandate was to build a lot, quickly, from scratch, and alone (we’ll delve into the specifics of the role later on in the post). Completely a fluke on my part, but interesting to observe in retrospect.

June (and into July) 2025 was Claude Code’s break-out moment.

Claude Code NPM downloads chart

And literally in my first week, Dax and crew release OpenCode in GA.

I got my new company’s approval to pay for a year of Cursor (for which I was super grateful), but being my first week, and also being a startup, I was too scared to ask for another subscription to Claude.

But lucky for me, my GitHub Copilot subscription still had about 6 months on it. And even luckier, you could plug GitHub Pilot into Opencode and use Anthropic models.

So in summary, my toolkit starting around June 3rd, 2025 was:

  • Cursor. IDE, best-in-class tab completion and small-scale agent stuff

  • Opencode (powered by GitHub Copilot) for my agentic TUI

I was off to the races. Just me, Cursor, and Opencode, building a full SaaS with 1000s of users from scratch.

Let’s talk about how I was using AI at the time, and where I was finding most leverage.

AI utility as a founding engineer

I’ll ramble a bit about the context of the company I was joining here, not to shill, but because I think it’s relevant to understanding how AI was useful in my first major project at the company.

Tax Nuggets Academy is an online learning platform for accountants; live events and an on-demand video library of Australian tax education where all consumption is tracked as verifiable Continuous Professional Development time (CPD). “Founding engineer” is my title (still here as of Feb 2026), but really I was just the first engineering hire who would fill the ex-technical cofounder’s shoes; the company was founded well before I joined around 2021, and already had strong product market fit and revenue.

The problem was their whole “online” product was a collection of off-the-shelf tools stitched together in a hacky way; they barely had any of their own code. They did things that didn’t scale to get to PMF, but now they were trying to scale the product because they didn’t own their tech.

So, my mandate was simple: rebuild this whole thing from scratch yourself. You’ve got 6 months. Make no mistakes :D.

So like any rebuild, I essentially had 2 main tasks:

  1. Build and deploy the application from scratch

  2. Migrate all the data to the new system

AI for data migration: mostly vibes

I’m going to start with the second task, because it was the most interesting as it relates to AI.

The data was in a few different places:

  • MongoDB

  • Uscreen (a video CMS)

  • Firestore

  • Bubble (yeah, don’t ask)

And I wanted to pull it all into a single Postgres database (the promised land).

Enter my second “oh sh*t” AI moment. Uscreen’s API wasn’t sufficient for our needs, so we needed a customer scraper. So, I let OpenCode and Sonnet 4.5 loose on this whole thing.

More-or-less, I told it, “here’s the source HTML for this page, here’s my authed cookie, build a scraper to scrape every video, transform and load it to our new database, etc.”

It wrote a full Uscreen scraper in Python/BeautifulSoup to pull the entirety of our data off of Uscreen, back it up to Google Cloud Storage, transform it as necessary and push into our new Postgres data model (the Uscreen API wasn’t sufficient for this btw, hence, scraper).

I barely read any of this code; it was one-time use, not running in production, and I had the rest of the system to build. I can’t underestimate how much time and pain this saved me.

My reaction to this was so visceral, I wrote a blog post on how I felt like I was cheating in my job - I really did feel this way, that I’d be “found out” for using AI at work. Crazy times.

Building the app

For building the actual app, AI was definitely useful, but I still ended up doing a lot of it by hand. As the only person responsible for this project, my job, and to large extent my reputation and career were on the line, and there’s no way I could trust whatever Sonnet was spewing out for auth, or access control, or billing or other core business logic. I felt I needed full control and oversight over most of it.

Some it was definitely vibes though.

One thing I felt very strongly about was building an agent-friendly codebase. The criteria for this continues to evolve but for me, it meant the following:

  • Monorepo (using turborepo)

  • Everything-as-code: Infra (pulumi), emails (react-email), billing config (Stripe)

  • End-to-end, strict typesafety: NextJS, shared monorepo packages for common stuff like database types, etc.

  • Use popular, well-documented tools and services if required: Firebase Auth

I feel this has continued to pay dividends for us, and hopefully those dividends accelerate in the future.

UI

A bunch of the UI code was AI-generated for sure. Once I’d installed my desired ShadCN components and tweaked the component styles to my liking, AI was super useful in the grunt work of implementing stuff like data tables with filter/sort and pagination.

That being said, I hand-coded most of the UI. Mainly because we didn’t have a designer or any designs to work with: design and implementation was a fluid process where I’d build something, use it, tweak it (or redo it altogether).

To this day I still don’t trust AI to build me good UI, that integrates well with my existing product. Maybe it’s just me!

But, I did selectively use Cursor Agent mode. To this day, my main usecase for Cursor is the ability to highlight a block of code, Command-Shift-I to add the reference to chat, and tell the agent to do something. “Pull this out into its own component”, “make this look like this instead of that”. This feels quicker to me in select cases: it saves the agent a few greps, minimises ambiguity, and reduces blast radius.

Mental game

This was a pretty stressful period of my life: the weight of this whole rebuild on my shoulders, no one in the weeds with me, I was constantly on the edge of burnout. There was a lot of work to be done and not much time to do it; it simply required long hours.

But having AI in my back pocket really helped with my mental fatigue. Not having to stress over every little hand-coding detail, not having to be in deep thought for many hours every day. Call it a skill issue, but honestly I’m not sure I would have held it together had it not been for AI.

November / December 2025

We launched the rebuilt product on November 3rd, and I finally had some room to breath and catch up with the latest AI stuff. In late November, Opus 4.5 drops. And this is where my terminal usage really started to overtake Cursor.

For context, apparently I ended up a top 22% Cursor user despite only using it hardcore for 5-6 months of the year.

But December was my first foray into full-blown agentic TUI goodness.

It started with just one opencode session: create this feature, push and create a draft PR for me to review. But of course, I immediately felt bottlenecked by both the agent’s slowness (tokens per second) and my own code review speed.

So naturally, it evolved to a second opencode session in parallel, working on some other unrelated bug, or helping me plan my next feature. And then a third, and so on.

I was beginning to see the power.

Note that at this stage I’m STILL not plugged in to any MCP, I’ve got the most basic AGENTS.md imaginable, no skills, nothing fancy.

February 2026 (now)

I - the human - am well and truly the bottleneck to velocity at this point. Me, and the roadmap. Being the only one thinking about product and also building, my roadmap planning hasn’t been able to keep up with my shipping pace.

I resonate so strongly with Karpathy’s recent sentiment, that “I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year”.

But, I’m improving.

For example, I’ve now got some MCPs installed, most notably Linear. I’m a huge advocate for async work and trying to keep a single source of truth for company work and projects, and Linear is that place for us. But now, it can also be the source of truth for agents.

My current toolset

  • Opencode hooked into work’s ChatGPT Teams (codex 5.3)

  • Linear Agent for the whole team: issue creation, triaging and delegation within Slack

  • Cursor agent for assigning small Linear tasks on mobile to create PRs.

  • Codex CLI /review command for reviews (I get paranoid that the model providers’ harnesses may actually be better, and I’m happy not having a good UX for a single, isolated command a few times a day).

  • Cursor as my IDE, but purely for reading code and isolated agent refactors. Composer, codex, opus or sonnet-only.

I’ve tried worktrees and hardcore parallelisation. It’s decent, but again, see above: roadmap bottleneck. Maybe a skill issue - stay tuned I guess! I’ve tried the new Codex app too, which does seem to make worktrees a bit more manageable.

Notably: I really like Opencode. I just hate the idea of committing to something like Claude Code, then someone else comes out with a better model (for instance, right now with Codex), and I’m stuck using something subpar.

On costs

My team already had the ChatGPT team plan, so I just asked for a seat; I think its $25 a month. This, plus the year of Cursor I already paid for is my only AI spend. This feels incredibly low to what I see online, but I’m still rarely hitting limits. Maybe I need less meetings :D.

As of right now, the meta has swung to OpenAI and Codex, so that’s who’s getting our money at the moment. Who knows, next month we could all be back to Opus or something else. Related: that’s the beauty of opencode: one TUI, one UX, don’t need to switch tools whenever the new models drop.

On workflow

Our typical flow is now something like this:

  1. Someone in the company has an idea or request

  2. We tag Linear agent in Slack to create an issue

    1. If its a small, well-scoped thing, I’ll assign it to Cursor agent, which will go off, make the change and prepare a GitHub PR for me to review
  3. I’ll fire up opencode with Codex 5.3 high, paste the Linear issue URL in and say “help me plan this”

  4. It comes up with a plan, writes it to the Linear issue => single source of truth that my [future] team could pick up and run with without me

  5. Then: “build it”.

  6. I review. Push PR.

  7. Finally, fire up codex CLI for a /review on xhigh

I’m still reviewing everything very closely, still manually testing everything locally, on staging and in production. If the site goes down at 2am, my CEO is calling me, not codex ;). So I still feel very much responsible for everything that goes out.

But even then, the trend is heading in the opposite direction, and the pull to let go even more is stronger than ever.

On the codebase

More vibes necessitates more discipline in the codebase.

Your types have to be bomb-proof. You need E2E tests. Your code architecture and organisation has to be solid. You’ll likely want agent-browser .

You gotta do everything you can to make the agent’s life easier. And fortunately, this almost always makes the human’s life easier, too.

On Velocity

I’ve been fairly religiously assigning estimates in Linear (Fibonacci estimation: 1, 2, 3, 5. It’s just what we used at GitLab and I liked it).

So I asked codex to look at Linear for all the stuff I’ve shipped in the last month, and estimate how long it would have taken without AI. 2.3x faster it reckons! Note that I probably only spend 70% of my time building at the moment. Obviously a crude methodology, but likely directionally correct.

The time is now

As someone who got into this industry to build useful things, it’s a great time to be a capable software engineer. I can now build stuff and deliver value at least 2x faster, which is a helluva drug.

It will required you to let go a bit. To achieve real gains, you can’t be sweating over every character anymore. Code is a means to an end, not the end itself. Always has been, but now more than ever.

If you have AI tips, please DM me. Let the tokens flow :)