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.

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 :)

We’re in the thick of the “AI is good or bad for code” debate in the software development community. Vibe-coders praise AI for productivity gains, while skeptics caution its use for various, often valid, reasons. As someone with a day job and also a handful of side projects, I can relate to both sides, and I’m using Copilot and Cursor on the daily.

But here’s a perspective - a phenomenon - that I don’t see talked about much. I feel guilty using AI.

I don’t know why, but I feel like I’m cheating. Like I’m doing something illegal, or at least unethical. It’s difficult to articulate, but it just feels wrong.

I don’t mean this in some hyperbolic sense. When AI completes the function I was about to write in one-shot, perfectly, I feel…inadequate. Less-than. In such instances, AI is objectively making me a more productive developer, and the value I can provide to society has increased. I guess I should feel good about this. But it’s leaving a bad taste in my mouth.

Is it pride?

On reflection, I do feel proud that I’m capable of creating something from scratch, of building something “with my bare hands”. In some ways, the AI revolution for programming is similar to the photography revolution. To get a portrait of your family pre-cameras, you’d commission a painter. The painter would attempt to recreate your family on canvas brush and paint over hours, or days, sweating the details to produce a 1-of-1 artwork. A skill that, to do well, requires years of practice.

Now imagine handing the painter a digital camera. Instead of taking hours to produce a single portrait, they can ‘produce’ hundreds of family portraits in an hour.

Objectively, this painter-now-photographer is more efficient at their task of producing family portraits. But to them (or at least some of them), I’d guess they have a similar feeling to me: that using the camera is cheating. That if someone ‘found out’ that they were using a camera, they’d be ridiculed (not the best example, but you get the idea). That one day, they’ll be called upon to create a portrait without a camera, but they’ll have forgotten how to paint. That it betrays the reason they got into painting in the first place.

Is it my education?

The university system - perhaps to a fault - optimises for rote knowledge and the ability to complete tasks under ‘exam conditions’. Back when I was completing my engineering degree, it was common to share assignments to get a collective leg-up and save time. But to pass the course, you had to pass exams, and to pass exams, you had to be able to do stuff ‘by hand’, from scratch - writing algorithms, solving math problems and so on. Maybe I have some latent anxiety from this period, where I’m (unjustifiably) worried that one day AI will ‘go away’, and I’ll be standing there as the senior engineer with no clothes on, unable to write code.

Perhaps this all a realisation that, while AI is a net-positive for software and the world, the act of programming, the profession of software engineering, is evolving to something I just vibe less with. Commanding an AI editor to do stuff around my codebase makes me more efficient at my job, yes. But like the painters of old, I feel guilty that it’s not me putting my brush to canvas.

Clutching on to pre-AI software development approaches is clearly suboptimal. And maybe it’s on me to accept and embrace this new reality to cure my guilt. But maybe there’s something to a little guilt-free coding every once in a while, too.

Do you experience AI guilt?

Committing this sin means more bugs. It means a less maintainable codebase. It means longer, lousier code review. And worst of all, it doesn’t feel that bad; it’s an innocent crime and not an obviously terrible idea. But, it is.

The sin, my friends, is big pull requests.

A big PR is the biggest sin in software engineering.

Wait! Don’t leave yet. I know, this sounds like another obnoxious Hackernews dev tip. But eliminating big PRs from your life will put you ahead of 90% of software teams.

The remedy to big PRs is, not surprisingly, small PRs (doctors hate him!). But this is easier said than done. Let’s explore the problem of big PRs, and consider strategies for making them smaller.

The problem with big PRs

As I mentioned, on the surface, big PRs don’t seem sinful. After all, a big PR implies you’ve done a lot of work. Yay for you! But sadly your big PR has three negative side effects:

• Longer time-to-merge.
• More bugs.
• Harder maintainability.

When it comes to PRs, size matters.

So, how big is too big? Well, 1000+ lines changed, certainly. But I'm skeptical seeing PRs at the 500 lines changed level, too. I'll take a stance: if your PR is above 500 lines changed, it might be too big.

Let's dig into why.

Longer time-to-merge

Time-to-merge means what you think it means: it’s the lifespan of your PR. The time it takes for a PR to merge. Time-to-merge is a function of your code review process; the longer the code review, the longer the time-to-merge.

Our goal should be to get time-to-merge as low as possible. 7 days is okay. 2 days or less is best.

If you have PRs open for longer than 2 weeks, you have a big problem. And that problem is likely that your PRs are too big.

The longer a PR stays open, the longer it takes for your user to get the feature. Obviously. What’s less clear is that the quicker you can get code into production, the better. Every dev learns that code takes on another life once it’s in production. And there’s only one way to know how your code will perform in production: ship it.

Big PRs tend to stay open for longer. For one, it’s harder to keep them up to date with the main branch. Not much worse than rebasing a massive PR that’s a week out of date. You know the feeling!

Beyond merge hell, review cycles tend to be longer.

As a code reviewer, you’ll spend more time reviewing big PRs. You need more focus. And you’ll leave more comments, of lower quality, leading to more back-and-forth with the PR author. Reviewing a big PR throws your whole day off.

All told, big PRs result in wasted time. I hesitate to use the word “waste”. But given there is a remedy (smaller PRs), this is time you can save.

More bugs

Imagine you’re reviewing a PR with 1000 lines changed across 23 files. How good is your code review going to be?

Be honest. Your code review will suck. You’ll catch fewer bugs, leave less instructive feedback, and be less patient with the author.

Nobody likes reviewing big PRs. So why would they yield a good review?

On the flip side, reviews on smaller PRs are almost always better reviews. The code review is no longer an overwhelming task. You’ll be more inclined to dig deeper into the code, more inclined to test the feature, and far more likely to find bugs.

The same principle applies to the PR author. A big PR means you’re keeping a lot of context in your head at once. We all like to think we’re good enough to do this, but we aren’t. Smaller PRs reduce the scope of the problem. With smaller PRs, you’ll take more time with code quality. You’ll introduce fewer bugs. And you’ll build better software.

Poorer maintainability

Ever tried reverting a big PR? It’s not fun.

The more code introduced in a single PR, the harder it is to revert.

And remember how big PRs yield worse code reviews? Well, that’s going to affect the maintainability of your codebase.

What about how it’s harder to author a good big PR? Maintainability suffers here, too.

Create smaller PRs

So, create smaller PRs! There are two approaches I’ve seen work well: feature flags, and stacked diffs (or chained PRs).

Use feature flags

When I learned how to use feature flags in development, I felt like I was unlocked.

A feature flag is a toggle you use to show or hide a feature in your app. Don’t want to release a feature to users yet? Put it behind a feature flag until it’s ready.

Feature flags can be as simple as boolean items in local storage, or as complex as using a third-party SaaS. Choose whatever your team will actually use.

“But Tom!”, you might say. “Why not simply have a feature branch? We can create smaller PRs that target the feature branch, and when the feature is ready, we merge it to main!”.

Many teams do this. But if big PRs are the biggest sin in software, then long-lived feature branches are the runner-up. Long-lived feature branches suffer all the same problems as big PRs. It’s painful to keep them in sync with the main branch. Your code stays out of production for longer, so you might get a big surprise when you finally merge it.

Feature flags solve this problem. Add a feature flag, and start merging small PRs behind the feature flag. When the feature is ready, turn it in and give it a test. When you’re confident in the feature, remove the feature flag.

Let’s say you had to implement the following feature:

When the user enters a value and clicks “Add Juice”, open a confirmation modal.

You could build the whole thing in one go. But then you’d end up with a 1000+ line PR. And now we know, big PRs are a problem.

Instead, you could build this behind a feature flag. In your first PR, you’d add the feature flag, along with code for the input field and the “Add Juice” button. The feature isn’t done yet; clicking the button doesn’t do anything! But that’s okay because we’re using a feature flag. Then in the second PR, you’d add the code for the modal. You might even have a third PR to refine the UX further.

Instead of a thick 1000+ line PR, you’ve shipped 3 small PRs. Woot!

Feature flags are your friend.

Stack your PRs

Sometimes feature flags are overkill. Sometimes all you need is to stack your PRs.

Stacking, or chaining PRs is what it sounds like: instead of one big PR, you could have three small PRs linked in a chain. The third PR depends on the second, and the second PR depends on the first.

This works well in situations where you need to refactor a bunch of code before building your feature. Instead of one big PR that includes the refactor and the feature, create one PR that only includes the refactor, and a second PR that includes the feature.

This way, each PR is reviewed and tested independently. Your time-to-merge will certainly be shorter, and hopefully, you’ve received a better code review.

If you’re really lucky, you might not even have to chain the PRs. If you can find a way to break up your big PR into multiple independent chunks, then you have achieved mastery. Pass your on-call shift to someone else!

Big PRs are a problem. They increase time-to-merge and lead to a buggier and less maintainable product. Do yourself and your code reviewers a favor. Create smaller PRs, with the help of feature flags and stacked PRs. Sometimes you can’t get around creating a big meaty PR. No worries. It just means you owe your team a small PR next time.

I tweet about building software in web3 and crypto - follow me over there: https://twitter.com/aeolianeth