AI and I

The last few months of my life as a software engineer working primarily on my own SaaS product have been chaotic. I am in serious need of taking a minute to sit down with my thoughts, to think through the different workflows I've adopted just this year alone, and how my work is changing, how the entire industry is changing, what that looks like for me, and how I feel about it.

And it's important that I do, because the pace of change this year to my workflows and to the products I work on has been so intense that I'm losing track of the permutations. Just as a I get used to one model, one harness, a technique, there's seemingly something new to move to and each time I see improvements that are worth changing for.

Going forward I feel like dev logs are going to become much more important not just for me but for every professional software engineer. When our code and tools are moving at a pace which becomes hard to keep up with, our dev logs that work at the speed of our brains and ground us in our evolving thought processes are going to become one of the most valuable tools we can implement.

Evolution to agentic development

My journey to adopting agentic coding practices into my daily work have followed a path which I think will be very familiar to all devs.

1. ChatGPT as a sounding board

Circa 2023 when ChatGPT was having its moment I started essentially just 'playing' with ChatGPT in the browser. The first thing I did was give it a mock coding interview where I just threw coding interview questions at it and watched as it mostly did a pretty good job at answering. I really didn't touch it again for months after this until one day I found myself working alone and really feeling like I just wanted a sounding board to talk about a project.

This was really the early stages of me introducing AI into my work. The thought of actually using its output in production code was still totally off limits to me, back then we didn't even really know what the copyright situation would be, if we were even really 'allowed' to use its output.

2. ChatGPT copy and paste

I think it was around when 4 was released and the first 'this is it, we're cooked' Tweets started to hit the world, I started to use ChatGPT to do real work. I was only trusting it with small tasks, I'd usually write out a method signature, a name, a set of inputs, and an output; ChatGPT, fill this in.

Even that was a pretty good time saver and very akin to the kind of work I'd have given to a junior developer on previous teams. It was still far from perfect at this stage. Most things still needed at least minor rework. But I was saving time and I could see this was going to be something. I think I thought at this stage this is as good as it would get, but even so, it had its place.

3. GitHub Copilot

I briefly subscribed to Copilot and used the plugin inside IntelliJ. I got really varied results where sometimes it would work and save me some time, but most of the time I found it was auto-completing absolute garbage that was just an annoyance to dismiss and that the chat was just really clunky.

I actually went back to #2 for some time after this, ChatGPT copy and paste.

4. Jetbrains AI with Junie, Claude and Codex

This was the beginning of the turning point for me. In all of the previous phases I was getting some value from AI but it wasn't embedded as an indispensable part of my workflow. I could easily not use AI for tasks and often wouldn't for the vast majority of large features. I was just farming out the boring stuff that was reasonably straight forward and copy pasting from ChatGPT in the browser back into my IDE.

It was the agentic chat mode in Jetbrains AI using Junie where I went from farming out single functions and tests to having an agent write the first draft of an entire feature before patching it myself.

5. OpenAI Codex, GPT-5.3-Codex and GPT-5.4

Without thinking much of it, somewhere in between using JBAI and Junie for most things, I decided to try the OpenAI Codex macOS app. I didn't think much of it at the time, I really just wanted to see what it was after reading about is release.

But it's changed my workflow again. I now barely open a full blown IDE (at least for web development, Android and iOS both pretty much require their respective development environments without significant effort invested in purposely avoiding it.) Most work starts in Codex, is tweaked, and then reviewed in GitHub.

6. Codex, Claude Code, Dispatch, Claude PR action in GitHub

This is where I am now. I have pro/max plans and API plans with OpenAI and Anthropic. I've cancelled my subscription to Junie/JBAI (and to PHP Storm, but more on that another time)

My workflow is the same as in #5 but I sometimes use Claude instead of Codex. I will reach for Codex with GPT-5.4 at this stage, that will likely change. But for now I'm finding it much more capable at most things. I will however opt for Claude Code for UI related tasks, particularly front-end web. I don't know why but Claude just does a much better job at UI, it will usually produce something much more aesthetic by default, compared to Codex's utilitarian UI design style.

I also have a GitHub action setup to @ Claude into the PR conversation and get a review. I don't use this on every PR, but for larger changes or changes that are higher stakes, I'll @Claude in.

I have a fairly extensive set of guardrails in place for my main project that was originally written as a Codex skill and that I've brought into Claude as well. I've also made (using Codex) a project specific prerelease.sh that runs my units, end to end tests, linters and package vulnerability scans and echos out in an ultra minimal context window friendly format.

Sometimes I will use worktrees, but having gone through an initial phase of using them all the time, I've found I prefer to not. You can get more done at a time with worktrees, but there's only so much I can review and keep in my mind at a time. Having 4 or 5 different features sitting on worktrees ultimately just ends up being a queue for me to have to process. For my brain, it's easier to just work on a local branch one feature at a time.

Where I've been doing my reps

I have a reasonably large B2B2C SaaS that is my main day to day project. Most of the learning I have done with AI has been on this project. Suffice to say there's been a lot of branches and worktrees that have never made it off my laptop.

Before I started committing agent written code to this codebase it was a 2 year old project with many established patterns, over 650 handwritten unit and application tests, and many pages of inline documentation.

The inlining of the documentation is just something I got lucky with. I wanted to move away from keeping information in Confluence, as a one person team there wasn't much benefit to it, having a docs directory full of md files actually just worked better for me. As it turns out, this inlining of documentation works great for agentic development.

Because this was a fairly large codebase going in, with established patterns to copy, an existing testing framework I had written by hand and trusted, with inline documentation to boot – I think I saw value very early on in agentic development.

Now that I've combined this with a combination of guardrail skills and codebase specific tools that have been written by agents for agents (compressed context window aware output), I'm regularly getting really good results the first time from agents.

Psychology of change

If you've been a software engineer for a long time. If it's part of your identity. If you've spent a large part of your life caring about code, code quality, and architecture. If there's books about code quality and how to be a better software engineer on your shelf. If you've ever considered code to be art. If this is your craft. Then there's no way you've escaped some kind of psychological toll as our industry changes so drastically and at a pace that feels almost instantaneous and is trending towards our skill set being a lot less valued by the world than it was mere months ago.

During this time I've been observing those around me. I've watched all level of engineer working across different stacks and industries go through the inevitable stages of acceptance. First AI was cool but mostly useless. Then it was a better auto complete. Then it was a good way to fill in a method signature or write a unit test. Then it was trying out various combinations of models and harnesses, still not being convinced, until one day the right model and harness combination clicked and they could see what everybody was seeing. I've seen this exact process play out multiple times now, even with the kind of engineer I thought would never accept it.

My own expectation of what I can get done in a day has changed drastically. Things I would have easily accepted would be a fortnight or months long epic are now done in a day or two. These days if I don't get multiple of these kinds of jobs done in a day, I'll usually feel unproductive.

A thought I am still working through myself is what is my job now. I am ultimately still a software engineer, even with all this extra productivity, I still don't see this work as something that can be done without a strong technical background. Though with that being said, I do believe there is a large subset of software engineering work that is now gone; things like building MVP's for non-technical entrepreneurs as just one very obvious example.

Regardless of any argument about the value of LLMs and SWE going forward, we can't change the perception society has on software engineers now. The value of the craft has been diminished in the eyes of the world. That's something that's going to change how we feel about ourselves, regardless of how true it is or isn't.

Claude has one-shotted my brain

Out of everything there is to worry about when it comes to this shift the only one I really find troublesome personally is just how profoundly this new paradigm has affected my brain when it comes to coding.

When I first started programming I didn't have an IDE. I use to write out setters and getters by hand. I didn't mind at all, it was repetitive and boring but no part of me minded doing it, it was just part the work.

But then I started to use IDEs and found the generate getter/setter feature that lets you just highlight your properties and generate getters and setters for them in a microsecond. From that point on, I couldn't stand writing out getters and setters by hand any longer. It just felt like torture to have to do it by hand knowing it can be done reliably in seconds by a bit of code.

The same thing happened when I start using refactoring tools of the IDE. Changing variable names by hand and finding each place it was used, was not only error prone, but genuinely hard to do knowing there was a better way, when the refactoring tools weren't available.

You can see where I'm going here. Claude has one-shotted my brain for most programming tasks. If you cut my access to all of these models tomorrow and forced me to do my work by hand, of course I could do it. But it would feel exponentially harder. I'd feel the same as if you asked me to mow my lawn with a pair of scissors. I could do it, but the whole time my brain would be consumed with the thought of how unnecessary this is and how much more productive I would be if with my lawn mower.

This is the sad part. Coding is something I genuinely enjoy. The reason I pursued this career is because it felt like getting paid to play. That's not to say I don't enjoy it anymore, I definitely still do. However I think the way I think about and feel about coding now is likely similar to what somebody who worked in Assembly felt when higher level languages entered the scene. Yes – you could still go on writing Assembly, in fact in cases you have no choice, but for the most part, why would you. In fact doing so would just be an unprofessional choice for most projects. This is what writing code by hand feels like now. There are times when you still need to, but for the most part you don't have to anymore, and we're already beginning to see that to remain competitive in the professional market, you'll have to start with AI; only dropping back to handwritten code when the agent doesn't quite get it right, like a systems developer dropping back to Assembly when that one thing needs to be closer to the metal.

This has happened before with the framework revolution. Before there was a new full stack web framework every two weeks, developers would just write each application from scratch, maybe bringing along a collection of snippets or utility files that would get copied and pasted across projects. For a time, that was a completely acceptable way of working. But once frameworks showed their value, you couldn't reasonably start a professional project without using one. The time investment needed to work without one and the risk of not benefiting from mature components is just too great for the vast majority of projects (we're going to ignore big tech here because that's the exception that proves the rule).

Things are simple

Don't complicate things unless you know exactly why you're complicating it and you can see the benefit it brings.

Most things with agentic workflows are much simpler than what some people will have you believe. There's no shortage of social posts and blog articles telling you that you need to use some tool or adopt some technique (ahem Ralph Wiggim) to be doing agentic development correctly. People like to talk. People also like to position themselves as an expert, particularly on emerging topics. There's also money in doing both of these things. I think anybody who has adopted agentic development into their workflow and has been using it for even just a month or so on a real project can see through most of these immediately.

Anthropomorhphisation "You are an expert security researcher", "You are a CEO" – these things don't work. Although it might help you in some way to imagine your agent as an antrhopmorphised being working a traditional corporate role, these incantations don't imbue the agent with any additional skill themselves.

Worktrees – handy, but also a slightly slower slightly awkward workflow. I can see why Peter Steinberger says he just uses multiple local copies of the codebase instead. Ultimately when everything is pushed and merged upstream, it's a quicker way to work. Though worktrees seem pretty well baked into most of the AI desktop app workflows now and because it's ultimately a cleaner way to work if not quicker, I think they will stay. I do love seeing a rarely used kind of obscure feature of Git suddenly become one of its most used features.

Prompting too

Prompts can be scarily vague.

There is value in context engineering and prompts are our biggest tool in controlling the output of an LLM. But those prompts can be much simpler than you might expect. When I first adopted an agentic workflow I was writing huge prompts for every change, thinking of every edge case that needed to be covered, describing every detail. But now, I've written some scarily vague prompts that I didn't expect to yield anything and what the agent has given back is every bit as good as if I had fleshed out a page long prompt.

When trying to think through that my guess is this possible because a) AGENTS.md or your vendor specific equivalent b) your codebase is already a huge trove of context c) memory.

I haven't worked on a greenfields project prompting it into existence from the ground up. But I expect the vague prompts wouldn't work in that context. But once you have a large established project, with guardrails, you can write shitty prompts and the agent really does just figure it out. When you think of the context it already has and the training data, it makes sense; we might think we need to hold its hand to the nth degree, but if we just point it in the right direction and give it a few words of intent, it can use the context and its training to narrow down what we want to achieve quite well, there's likely only a handful of options in that particular part of the codebase, and it's good at knowing what would come next.

The things I care about have changed

So I have to be careful how I word this one, because developers are sensitive, especially when it comes to existential matters and the careers that form a large part of our entire personality.

The degree to which I care about code has declined somewhat. There are in my mind two levels of writing good code. Writing code that performs well and writing code that reads (maintains) well. I've always particularly enjoyed the latter. Finding good variable names, a simple flow through an execution path, designing units that can be reused and that extend well – this is the part of coding for coding's sake that I really enjoy. There is a definite art to it, taking something potentially complex and making it as simple as possible so that somebody joining the project new can pick it up quickly. It's a subtle art though that if done well is mostly invisible to those consuming it.

But that art is quickly losing its importance. We can look at well written code and architectures and appreciate them in and of themselves and in that sense they will always have some value. However, the reason we ever started to care about this stuff was maintainability. Maintainability is tied to business value and for a large swathe of systems the value of this maintainability is much less because change is going to be handled by agents, and because the business just does not care about the code; they never really did, they've only ever cared about the value they extract from it.

I personally think it's very important we maintain the ability to read and understand the code of systems you're responsible for. In my own projects, even though I am moving at a much greater pace now, I am spending as much time as possible reviewing PRs before they go in the system. My main project was written by hand before even the ChatGPT copy-paste era. With the speed at which I've been shipping new features since embracing agentic workflows, I can feel how easy it would be to miss critical changes and lose track of how the system evolves over time. It wouldn't then be long until one day I look at the system and it's as foreign to me as a codebase at a new job.

I work as a one person team, but I've always created PRs for new features regardless. This has always just been a workflow I'm comfortable with; something about viewing the PR in the GitHub interface as though it's somebody else's code lets me shift gear mentally in some way that gives me better ability to review the code. Agent created code slots into this workflow nicely.

Hubris as a Service

Not many people read my blog. At least not as far as I know, I don't have any analytics what-so-ever. But I know if you've read the above and you're a software engineer who cares about their craft, you'll have thought nonsense; code quality will always matter, and you probably think I'm a huge dickhead who has drunk the koolaid.

But the reality as far as I see it is that collectively none of us actually achieved that serene state of zen code we were striving for. Maybe it was good enough just to be aiming for it, maybe some of us came close some of the time and actually had something pretty good.

I've seen companies run for decades now on codebases that are mish mashes of open source frameworks with inline edits that can never be updated to the latest versions of the underlying framework because they wrote into the framework not on top of it.

I once joined a large tech company with hundreds of thousands of users whose name you would know if you're at all involved with wearable fitness gadgets. The iOS team I joined, 8 strong, all from big name companies before this one, had recently completed a big refactor to take the Objective-C UIKit codebase from MVC to VIPER. This big refactor to a complex architecture with a cool acronym looked great on the surface. Things were logically organised into their respective responsibility and it all kind of felt nice.

Except over time, the refactor itself became responsible for at least 25% of all bugs, and responsible for one of the most costly bugs the company likely ever saw. When the team implemented VIPER across the codebase they had introduced in nearly every part of the application a memory leak with some of the VIPER components holding strong references to each other and never leaving memory until the app crashed. This issue manifested in several different ways across the app with varying presentations of the bug. In one case, it had lead to a defect where an API call was happening 150 times every time a screen was loaded instead of once. 150 times across that many users at scale had a real cost. The worst part is, nobody actually caught this as a bug for months, the backend team had assumed traffic had increased for a genuine reason and scaled accordingly. The iOS team had no idea it was happening until it was caught by chance. When the bug was fixed, the head of the backend team announced the cost saving at a company all hands.

I've seen countless of these refactors and rewrites at all levels of company by all levels of engineer that were supposed to solve all the problems and were sold as achieving engineering best practice that will trickle down throughout the rest of the organisation to make everything great. Only to see them turn out to have their own sets of problems and essentially fail in different ways.

All this to say, even teams of engineers who are striving for best practice, whose work is their craft, who've read all the right books and have all the right knowledge – still ultimately end up presiding over a mess. There are very few of us who can say with a straight face we were achieving perfection before AI.

Don't get comfortable and keep your bullshit detector set to high

In this time that we're living through right now, you need to be constantly re-evaluating your workflow and your tools. At the same time, there is a lot of garbage being spat out into the world. That's partly because LLMs have made it so easy to build that garbage to spit, and partly because this is all so new to all of us.

Some want to position themselves as an expert in the field and releasing a tool is a great way to do that. Others have genuinely built something that works, and that other people have found to work for them too, but haven't realised that tool really might not be helping anymore because the model, or more likely the harness, now do that thing anyway.

If you're just starting out, start out with a blank slate with no tools and just using whatever prompts and techniques feel natural to you. A lot of beginners just getting started are seeking out tools and learning techniques before they even get started. I understand, some personalities need to feel like they've done some learning before they try a new thing for the first time. But if you start out with them without understanding the capabilities of the underling agent you'll attribute a lot of things to tools and techniques that really might not be doing all that much for you. You need to start from nothing and add tools in as you go, on a project by project basis. That's how these tools are designed and that's how you're going to get the most benefit.

Learning aside, I think there's a very real chance some of these projects will actually set your project back. Any tool you're bringing in that is just a collection of markdown skill files that purport to give you superpowers or a team of CEOs, product manager, and other anthropomorhpisms is going to be generic in nature.

These skills work best when they're specific to your project, when your agent makes a mistake and you add a skill so it doesn't happen again, or there's a certain way you like things done in places. Your context window is precious, you don't want the skills that worked for somebody else getting read in and clogging it with less than optimal tokens for your task.

The one exception I might make here is language or framework specific skills written by a person or group of people who have high domain knowledge. Things like telling Swift to not use Combine but to instead use Swift Concurrency (which you don't need to do because Apple has done it for you if you use Xcode 26.3 integration), or advanced SwiftUI techniques that achieve certain aesthetics, interactions or performance.