AI Coding Assistants: The $200 Monthly Investment That Pays for Itself - Lately the price of AI coding assistants has been climbing. Claude Code’s max plan runs $200 per month. Cursor’s Ultra tier is another $200. Even GitHub Copilot has crept up to $39/month. It’s easy to dismiss these as too expensive and move on.

But let’s do the math.

The Simple Economics

A mid-level developer in the US typically costs their employer around $100 per hour when you factor in salary, benefits, and overhead. At that rate, an AI coding assistant needs to save just 2 hours per month to pay for itself.

Two hours. That’s one debugging session cut short. One feature implemented faster. One refactoring completed smoothly instead of stretching into the evening.

I’ve been using these tools for the past year, and I can confidently say they save me 2 hours in a typical day, not month.

The Chicken and Egg Problem

Here’s the catch: how do you prove the value before you have the subscription? Your boss wants evidence, but you need the tool to generate that evidence.

This is a classic bootstrapping problem, but there are ways around it:

1. Start with Free Trials

Most AI coding assistants offer free trials or limited lower cost tiers. Use them strategically:

• Time yourself on similar tasks with and without the assistant
• Document specific examples where AI saved time
• Track error rates and bug fixes

2. Run a Pilot Program

Propose a 3-month pilot with clear success metrics:

• Reduced time to complete user stories
• Fewer bugs making it to production
• Increased test coverage
• Developer satisfaction scores

3. Use Personal Accounts for Proof of Concept

Yes, it’s an investment, but spending $200 of your own money for one month to demonstrate concrete value can be worth it. Track everything meticulously and present hard data.

The Ground Your Agent Walks On - Every codebase is terrain. Some are smooth highways, where AI agents can move fast and confidently. Others are more like an obstacle course - still functional, but harder to navigate, even for experienced developers. For AI agents, the difference matters more than you might think.

Matt Pocock recently tweeted, “Know the ground your agent will walk on.” It’s a great metaphor. AI coding assistants aren’t just tools - they’re travelers trying to make sense of your landscape. The easier that terrain is to read, the better they perform.

The Terrain Metaphor

Think of your AI agent as a sharp, capable junior developer. Fast, tireless, and helpful - but very literal. They don’t infer intent. They follow cues.

When your codebase has clear structure with focussed models, controllers that follow consistent patterns, logic that lives in obvious places then AI agents can hit the ground running. They know where to go and what to do. But when logic is scattered across models, helpers, and controller actions - when responsibilities blur and patterns break - it’s harder. The AI has to guess, and that’s when bugs, duplication, or missed edge cases creep in.

You’ve likely seen it: in a clean, readable codebase, the AI knows where to add password reset logic. In a tangled one, it might reinvent validation from scratch, or break something that silently relied on old behavior.

The Productivity Multiplier

Well-structured code doesn’t just help AI a little. It can make them drastically more useful.

Clean abstractions give the model leverage. Instead of spitting out code you need to carefully review or fix, it can offer changes that fit right into your architecture. The AI stops being just a helpful autocomplete and starts being a real multiplier.

How can we use AI without getting dumber? - DHH’s recent observation about AI resonated:

“As soon as I’m tempted to let it drive, I learn nothing, retain nothing.”

When he lets AI take the wheel, his learning stops. Knowing how you learn best is crucial and I respect that. But his tweet reminded me of my first week with Rails many years ago. One command - rails generate scaffold Blog - and boom. Working blog. Complete with database migrations, controllers, views, the works. I felt like a god.

For about ten minutes.

Then came the client requests. “Can we add comments?” “What about tags?” “Why is it so slow with 10,000 posts?”

I had no idea. I’d built nothing. I’d learned nothing. The only thing that had happened was some code appeared on my screen.

I know what you’re thinking: “That’s different. Rails generators create 50 lines of boilerplate. AI writes entire features, algorithms, and architectural decisions. One removes tedium, the other removes thinking.”

Fair point. The scale has changed dramatically. But here’s what’s interesting - in the early days, those 50 lines of generated code felt just as magical and just as dangerous to understanding. I remember the debates about whether generators would make us worse developers, whether we’d lose touch with the fundamentals. Some of us worried we’d forget how to write SQL or understand HTTP.

Sound familiar?

We’re watching the same pattern repeat, just amplified. With Rails generators, with Stack Overflow, with Google, with IDE autocomplete, and now with AI. Each time, the community splits: those who see a shortcut to ship faster, and those who worry we’re shortcutting our way out of understanding anything.

Both groups are right. And both are missing the point.

That Weird AI Workflow Might Just Work - Kieran Klaassen and team mates shared their Claude Code workflow a few days ago. They broke down their process, showed what they built, and yesterday Kieran posted about the (potential) API costs a workflow like this has (or would have if not for Anthopic’s Max plan). The response? While some were curious, the critical voices dominated - calling it too expensive and claiming ‘these AI folks’ aren’t building anything real (check out Kieran’s X feed to see how absurd that is).

Here’s what bothers me: Kieran wasn’t bragging. They were sharing data. They were excited about their productivity gains and wanted to show others what worked for them. And instead of curiosity or questions, they got dismissal.

The Real Problem

We all know AI is transformative. Nobody’s arguing that anymore. But there’s this weird gatekeeping happening around how people use these tools.

Someone posts about using Claude to write tests? “That’s not real testing.” Someone shares their Cursor workflow? “You’re just racking up API bills.” Someone shows how they built an app in a weekend with AI assistance? “But is it production quality?”

The critics are missing the point entirely. These developers aren’t saying their way is the only way. They’re experimenting. They’re pushing boundaries. They’re figuring out what works.

Why This Matters

Every breakthrough in development workflows started with someone trying something different and sharing it. Remember when people mocked developers for using Rails? “It doesn’t scale.” “It’s just a toy framework.” “Real developers use Java.”

Those early Rails developers weren’t wrong for sharing their excitement. They were pioneering new ways of building web apps. Some of their approaches failed. Others became industry standard.

Sure, not every experiment will pan out, and healthy skepticism has its place. But there’s a difference between thoughtful critique and reflexive dismissal.

Same thing is happening now with AI workflows.

Your Code Works? Prove It. - I recently opened a pull request on a new project and, along with the usual details, included a short demo screencast. I do these often because they’re low-effort but high-impact.

The code in the PR might be clean. The tests might be thorough. But nothing proves your code works better than running through it like a real customer would. Here’s the blank state, here’s the error state, here’s the working state.

As I record these short screencasts, I often spot issues, or I get a flurry of ideas worth capturing for future cycles, and the feature usually ends up better just from going through the recording process. Sometimes things pass unnoticed during development and only show up when you step back and watch it play out.

Most web developers are already clicking around constantly, refreshing the browser to test what they’re building. But just working is the baseline. How does it feel? Can you explain it? Did you need five clicks when three would’ve done?

I think reviewers appreciate the video too. It shows care. It can save them from pulling the branch just to see it in action. When a PR has beautiful code, solid tests, and a short demo, it’s a pleasure to review. Next time you open a PR, try narrating a 60-second walkthrough. You might be surprised what you catch, or how much smoother the review goes.

Prefer Writing - At the end of last year, I recorded 3 screencasts that I felt would be interesting to the Ruby on Rails community. I put them out into the world and the response was largely positive. But to me, it didn’t feel right. Recording a video to explain things does not come naturally to me. I prefer to write.

Whilst I don’t mind consuming screencasts, and I’ve learned a lot of Ruby on Rails techniques from fabulous screencasts like Railscasts, Destroy All Software, Go Rails and Drifting Ruby, and countless YouTubers, my preference is reading a long-form blog post or book.

Intro to Raycast For Developers - Quick demo of setting up Raycast to search the Tailwind and Devdocs documentation.

• Raycast - https://www.raycast.com
• Raycast Tailwind Extension - https://www.raycast.com/vimtor/tailwindcss
• Raycast Devdocs Extension - https://www.raycast.com/pomdtr/devdocs
• TailwindCSS - https://tailwindcss.com
• DevDocs - https://devdocs.io
• Matt Swanson Twitter - https://twitter.com/_swanson
• BoringRails - https://boringrails.com

Ruby On Rails Resources I Use Every Day - Here are a few sites/resources I have bookmarked that I refer to day to day when coding Ruby on Rails applications.

• https://api.rubyonrails.org
• https://guides.rubyonrails.org
• https://github.com/rails/rails
• https://railsdiff.org

Rails 'new' customizations for Rails 7 - With Rails 7 and its plethora of new javascript and css configuration options and flags, it can be quite challenging to remember just what these options are when creating a new app.

For quite some time Rails has had the ability to read in a config file you have in your home folder named .railsrc This file contains the various flags you would otherwise pass into ‘rails new’ manually. By putting your preferred options/flags into this file, every Rails app you create will be created consistently and just the way you like it.

I prefer postgres as my database and esbuild for my javascript processing and tailwind as my css framework. So my .railsrc file looks like this

--database=postgresql
--javascript esbuild
--css tailwind

Now I just start a new Rails app with

rails new brilliant_app_idea

And my new app is ready to rock configured just the way I prefer.

The Key To Winning In Business -

I have turned entire businesses around with this tactic and I encourage you to at least try it for one week and notice the positive difference.

Stand outside an Apple Store 10 minutes before they open and you will see a team meeting. Have a look at your favourite sports team before they play, they are having a team meeting. Every army command has a briefing before they do their mission. Every successful team, or team trying to win, has some sort of team briefing before they start a game. In a business environment, the “game” is that days trade. And its critical to the success of your business that everyone going into that day is armed with all the information and motivation to help you achieve your goals.

One of the biggest positive impacts in my career was the consistent use of morning meetings to inform and motivate my team.

What is a morning meeting or pre-game huddle? It’s an opportunity to brief the team on the upcoming days events, goals, challenges and generally getting everyone on the same page. There is a lot going on in any given day. Bringing everyone together for 5 minutes is healthy, easy and tremendously effective.

How do you conduct a morning meeting?

Just call everyone together. Time limit the brief to no more than 5 minutes (although you should be able to do it in less than 2) Let everyone know how things are progressing against the goal. Pick someone to congratulate for something they did well yesterday (be genuine, if there was nothing then skip this step, although if you talk to your team there is always something cool or interesting they did or achieved that moved things forward) Let them know or remind them of upcoming challenges and opportunities. Squash any rumours floating around. As long as you squash them with fact. Conclude the meeting with a reminder of what todays goal is. I used to mix things up (I was in a retail environment) and would set challenges for the day — things like ‘an extra 20 minutes lunch break for whomever sells Widget ABC first or first person to sell 10 of this Widget can finish work 30 minutes early today” etc etc. Competition is good. And Healthy. And you get some great observations out of it as to who is really hungry.

So why do morning meetings/team meetings/huddles work?

They keep team members involved. This is huge. A disengaged workforce will not work to help achieve your goals. They will simply do the minimum required to achieve their own — getting their weekly/monthly pay check. Involving them, making them feel part of the process has a massive psychological impact and their buy in will make them truly part of the team. There is no day to day ambiguity on what is expected. If you set a target to achieve X today, then everyone is aware. No need to speak to individuals. No need to send out a seperate memo. Everyone collectively knows what today is about. You can show your disappointment if things aren’t going well. A manager who is locked in their office lamenting and upset about poor results is significantly less effective than a leader who stands up in front of the team in the morning and states their disappointment at the results coming in. The important thing here is to balance that out with hope and tactics to turn the situation around. Being open that targets aren’t being met is a lot better than not talking about it, sticking ones head in the sand and just ignoring the problem. High performers in sales (although I’m sure in most other fields too) have egos that need stroking. They love the spotlight and the occasional mention of their great results in public will motivate them even more. You have an opportunity to talk about decisions and tactics you have made. A lot of teams are informed of a new policy via a memo without understanding the reasoning behind the decision. Your ability to put a human face on the policy will be very effective. Can this be used in any workplace?

YES! I believe so. Every business is trying to achieve something at any particular point in time. A factory needs to produce a certain amount of Widgets. A service shop need to see a certain amount of clients today and get a certain amount of new ones. The sales pipeline always needs filling. And if full, the output needs to be processed. There is always a target. If you haven’t been used to working with a target you need to put the thinking cap on (ideally involve your team) and come up with some. Once you do, start measuring and talking about it each day.

What if I only have 2 staff?

Two is a team, and you need to huddle :) It’s not hard. It may be quicker and may involve nothing more than reminding each other about some stuff coming up that day and when to best get lunch breaks out of the way.

What if its only me — 1 person?

Well you’re in luck. Obviously no meeting for you. However — I encourage you to take 5 minutes before you start work and think through how things went yesterday, and what the plan is for today. The effect will be the same. You will have anticipated problems and given yourself that little psychological kick to achieve something.

Summary If all this stuff sounds too hard or likely to be ineffective I can assure you it is neither. Like with any skill it requires practice. When you start, some meetings will seem awful, fake and boring. But over time you will get into your groove and be able to conduct them quickly and efficiently. You will know you’ve nailed it when the team claps and cheers at the end, pumped and motivated to smash todays goals.

Code For Today, Not Tomorrow - A developer will occasionally send me a pull-request that, whilst often technically excellent, has new code in it that is ready, waiting for some sort of future requirement they have convinced themselves will be needed.

A simplified example may be adding a birthday field to the users table. The developer will add the field, make the user form cope with the new field, but then also take it upon themselves to add a birthday_email_sent_at field, because they believe that surely we will want to send birthday emails to the user sometime in the future.

There are a number of issues at play here:

1. YAGNI (you ain’t gonna need it) — A popular term that describes this phenomenon. Building more than you need.
2. Small PRs. The more “features” tacked onto the PR the more unwieldy it gets. My philosophy of late is to try and get one commit into a PR. A small focussed, atomic change that can be easily reviewed. Sure at times this can be multiple commits if the change needs to be done in one merge. Readability is key here.
3. Testing — adding something “we may need in the future” puts strain on the testing systems. Not to mention adds time to the entire CI flow.
4. Shows bad design. If something is being added now, out of scope, because “its easier to add it now” show that the classes in question are too large and not focussed enough.
5. Lack of communication. If a developer honestly believes that an additional change over and above the brief is required then that should be communicated well and truly before a single line of code is written, with agreement from all stake holders. And even then it will probably become a new card/brief and another PR anyway.

A better way?

I recommend the following approach:

1. Make sure the cards/tasks assigned to developers are clear and unambiguous. It starts here. Don’t give your developers any breathing room for misinterpretation.
2. Make sure developers are comfortable asking you for clarity on the feature/request.
3. Reject PRs (or kindly ask that code is removed) that adds functionality or future proofing not requested on the card. This is more a training technique than anything. The more you push back the more the developer will come to understand that only the requirements of the card will be accepted. A good comment may look like “Can these lines be removed please, as not in the requirements. They look like an interesting add — can we discuss for a later stage?”
4. Use the rejected PR as an opportunity to also ask the developer how they could design the classes to be easily changeable should a change be required tomorrow.
5. Do all the above in a dignified manner. In most of these situations the developer is acting out of genuine care for the product. Ensure the developer isn’t left feeling like their mistaken or contribution was a waste.

Doesn’t this harm initiative?

No. Initiative is welcomed and encouraged. It’s actually a great trait to see in developers. Through communication and discussion, initiatives can be addressed and actioned prior to a line of code being written.

To get back to the birthday field example from above — a developer, using initiative, could have asked prior to development — “With this update, should I add a birthday_email_sent_at field? We’re going to be sending emails to customers at some point right?”

This starts a discussion, which is significantly cheaper than coding something for tomorrow that may not be needed.

What's Next - Occasionally we are presented with two features that we need implemented in our application. Which one do we do first?

The easy option is to do the simplest feature, or the one that will take the least amount of time to complete. However sometimes that goes against the goals of the business. It’s tempting to do the easy stuff. It ticks an item off a list. Moves a Trello card from one list to another.

There are some businesses that have no real goals. No idea who they’re targeting. What features their customers really need next. This lack of clarity makes prioritisation harder. If the goal is to create more signups then working on the easy feature to do with simplifying search results is not as important as making the sign up form clear and easy to use across all devices.

Mark Zuckerberg famously had growth as the big headline goal for Facebook in the early years. If the backlog feature wasn’t going to have a measurable impact on user growth it was shelved. Not a priority.

Feature prioritisation should be closely linked to business outcomes and objectives. Not how easy or quick it is to build.

Asking For Help Is OK - Last week I was stuck on a coding problem on some code I wrote a while back but that contained a nasty bug that had been intermittent and hard to pin down.

This particular application I had written myself before I had a team in place, so I was the only one that knew the codebase. Over the weekend I thought about the best way to keep tackling this problem and the solution I came up with was to involve another person.

This may seem like a no-brainer to some of my astute readers but here are some reasons why it wasn’t my first thought:

1. No one else knew the codebase
2. Pulling them into this problem meant pulling them off their own projects
3. It was a bug I had caused, so surely I was responsible for finding it and fixing it.
4. It’s probably a small, stupid bug and I will look incompetent to my peers/staff if I need help fixing it.

To me, at the time, these all seemed plausible reasons to keep tackling the issue myself. Problem is that I wasn’t getting anywhere. I was actually costing my company money by spending more of my time on it. It was unproductive and not effective.

So I asked my colleague to look at the problem. And then the magic started happening.

He cloned the repo and immediately ran into problems. Bundling wouldn’t work (this was a Ruby/Rails app). The README on starting work on the app was out of date. There was no solid database seed file. A whole slew of issues just getting the app bootstrapped onto his machine. Embarrassment turned into an opportunity to make the app better, document things better and making it easier for new devs to come onto a project.

After an hour or so he started to look at the initial problem. It was a JavaScript bug and adding console.log statements strategically started to highlight some issues. He sat at my desk and whilst I wasn’t paying 100% attention as he was still in discovery mode, I was hearing the frustrations and questions. Eventually I gave him my full attention and we tried a few things and solved the problem together. We high-fived each other, commited and deployed the fix.

At my work we try and pair at least once a week. Either on something challenging or to check out new techniques. Rarely do we do it when we are stuck on a bug. I think this example has shown how good it can be to get another set of eyes onto your code, either through pairing or pull-requests.

As a manager of a project, it can sometimes be confronting to get a colleague or team member to review your current or older code. You are meant to be be the guru. You are meant to help them. But you know, we all have rough days. Sometimes we don’t write our best code. Sometimes we can’t see the cause of a particular bug. Asking for help is the right thing to do.

Just Publish It - A lot of companies have blogs and news sections that are stale and not updated often. I’ve long been a proponent of keeping websites updated, particularly the news/blog section. It’s a sign of a healthy business that it is keeping its online face up-to-date and giving its clients (and more importantly potential clients) a sign that the business has a pulse. That it is doing something.

I’ve seen a lot of companies prepare some great blog posts - in draft format. Too scared to press ‘publish’ because the post is not ‘polished’. Not ‘perfect’. I’m not sure if there is a real fear that publishing the imperfect post will send the companies stock plummeting or clients fleeing in droves? Perhaps its an imagined fear that all things must be perfect in business.

My advice is - just publish it. Obviously run a spell and grammar check. Perhaps even have a co-worker read it. But publish it. Let the world know the business has a pulse. That things are happening. If the post was worthwhile typing out, it must have been important to you for some reason. It doesn’t need to be perfect for it to resonate with some of your readers/visitors.

I believe your business will suffer more from not publishing anything at all to publishing an allegedly imperfect blog post.

How I Tackle My Email - We all hate email. Or at least we should. It creates work. It sucks precious time from our day. It causes endless interruptions if not managed properly. It can control us.

I have read many a book, blog article and tweet on how to manage emails and thought I would share my recipe for slaying the email monster in an efficient manner.