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.

Daily backups and diffs of ONCE Campfile source code - When you purchase Campfire from 37Signals, you will be able to download the source code. This download is a ZIP file and includes no git information. You do need to include your purchase token in the url of the download and if valid the source zip will download.

You are permitted of course to push that code to your own private git repository. By adding the Github Action workflow file below to your PRIVATE Campfire repo, Github Actions will download the ONCE Campfire code, unzip it, and then push a commit with todays date. You will then have nice diffs of changes made to the source. If there is no changes then no action will be taken.

Using specific Node JS versions in Github Actions - Sometimes you may want to run your Github Actions using a specific version of NodeJS (eg version 8). This can come in handy if you are dealing with a legacy application and needing to compile a specific version of node-sass for example.

The way to do it is to add the following lines into your workflow file.

- uses: actions/setup-node@v2
  with:
    node-version: "8"

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.

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.