How I Code Today

It was obvious that the way we code was going to change, but just how much is becoming more and more evident.

These days I scope up a bunch of epics in GitHub and then check back a couple of hours later to review and merge finished pull requests to be deployed into my app.

Here, I want to run you through how things have changed and how I work today.

I work on multiple projects simultaneously and am PM, Engineer, GTM and support at the same time.

Without the right setup, this wouldn’t be possible to this degree or would take a lot more time to do.

So let’s dive into all the latest buzzwords: loops, skills, MCP, cli etc.

Skills - the foundation

A skill is pretty much a predefined prompt for an agent, telling it what to do.

This could be this amazing Thermo-Nuclear Code Quality Review from Cursor, or it could be a set of instructions to use an MCP to fetch an error trace from your prod system and analyse a customer's issue more deeply.

I use these as building blocks in cron jobs, loops or just all sorts of ad-hoc work.

One skill here is my customer triaging.

When a customer reports an issue via email, I use it to let the agent parse through the email, identify the core problem and create a ticket for further processing. That saves me quite a bit of work in the day-to-day and feeds into the loop.

Loops - working through tickets

In my projects, I use GitHub because that’s where my code lives anyway, and it has a powerful CLI that lets an agent directly communicate with it. GitHub also has an inbuilt ticketing system: Issues.

It’s nice as coding agents understand this naturally, and it links into Pull requests. It’s also independent of markdown files that agents like to create but then live in the git history and are harder to track and search through.

If you do just one thing, utilising GitHub Issues to do scoping, maintaining and working through issues is a huge structural boost. Even without a loop.

A loop is a simple command-line script. It might look a bit like this:

For all tickets;

{

Use Kimi Code CLI with scoping skill to dig into the root cause.

Once clear, update ticket.

set ticket to ready.

}

I use two main ones. One for scoping up tickets; this includes evaluating architectural fit, focusing on the root cause and prioritising. The second is for implementation.

The implementation loop is a bit more complex:

1. It picks up the ready ticket with the highest priority and creates a worktree branch

2. It sets a goal and spawns a subagent that does the coding

3. Thermo-nuclear code quality review

4. Full test suite

5. User testing

6. Frontend testing

7. Pull request

With this alone, things get pretty hands-off.

10-15 issues in the queue; running the whole test suite will run for hours without needing me at all. All I need to do is review and approve the PRs.

More helpers

The loop and the skills rely heavily on MCP or CLI to function properly. Many companies support at least one.

Here are just a few. BetterStack for error tracking on prod. I combine that with a skill that runs weekly and checks for any issues and files tickets for each.

PostHog is used as part of my weekly SEO in combination with Pageseeds CLI. This will give the agent full context of how a site is performing, where traffic goes, and issues users might be facing.

MCP for custom workflow steps is mostly overkill, so here I usually go for a simple CLI tool to do something like email fetching.

Where will this end?

A year ago, I was still prompting agents to code certain parts of the app and reviewing bits and pieces, triggering isolated steps myself.

What has enabled this new style is not just model advancements, but also tooling. Kimi, Grok, Claude, etc. have all significantly improved on their CLI capabilities and enabled goal setting, subagents, skills, plugins, etc.

On top of that, a recent trend has been cheaper and more efficient models. This is usually what lets people like me with a limited token budget experiment. If I’m not constrained by token usage because it’s gotten cheaper, then I’ll automate everything.

This trend of better models, cheaper models and better tooling is only going to continue. Today I have to do most of the plumbing to set up and run this system; in a year’s time, Kimi, Grok and Claude will likely take care of all of this out of the box.

Continuing to push the boundary here will level the playing field for people with no coding skills and, at the same time, will push engineers towards solving more difficult problems.

An example here is indie hacking. A trend where an individual will find a niche and build software for it, starting a SaaS business.

Levelsio looks at this trend and argues that the traditional indie hacker playbook is dead. When finding a niche problem and building a software solution becomes so effortless that anyone can do it in an afternoon, the low-hanging fruit disappears. Micro-SaaS pricing gets driven toward zero, and standard apps become commoditised overnight.

I'm seeing a trend here of declining revenue and traffic with indiehackers

On my own projects too

Maybe big VC products too but I wouldn't know cause they don't share revenue

To me it seems clear BigAI is cannibalizing everything that used to be apps

Not bad btw, just times

— @levelsio

Instead of an endpoint, I see this as an ongoing cycle of moving up the abstraction stack. As the lower-hanging fruit gets continuously solved and automated, engineers are naturally driven toward higher-stakes, more complex problems. But as agentic tooling and model capabilities keep expanding, the playing field for those higher-level problems gets levelled as well—pushing us even further up the stack.

Software execution itself is becoming a utility, but the frontier of what we can build keeps expanding. Ultimately, the value isn’t disappearing—it’s just shifting away from the mechanics of writing code toward knowing which complex problems are actually worth solving, orchestrating the system architecture, and owning the distribution to reach people.