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.

[read more...]

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.

[read more...]

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.

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 To Leave A Job You Like For One You'll Love -

Do what you love and you’ll never work a day in your life - Confucious

Do you like your current job but dream of something better? Or perhaps you go to work and are constantly thinking about your side project, or hobby. This could be a sign you are in desperate need of a career change.

[read more...]

Greater Market Share does not always mean Better Product - Use of a particular operating system on any platform is largely a matter of personal choice. Sometimes, that choice is made by a business or corporation on behalf of their employees, and other times, individuals can make the choice themselves. I’m often seen tweeting or facebooking the virtues of Apples operating systems and products, often citing increased sales statistics or my own experiences in my message that Apples products give me a better experience than any of the alternatives. However, I often see mention that Android must be better because it has a higher market share. Or Windows is king because it has a higher market share. Higher market share does not always mean better product. A number of variables play part in determining market share. There are many cases where a product with lower market share, is simply the better product.

[read more...]

Websites are like fashion -

Facebook is like fashion. It never ends.

I was watching..or re-watching….The Social Network the other night and my ears pricked up as I listened to some dialogue between a young Mark Zuckerberg and his equally young financier, Eduardo. They were celebrating the fact that The Facebook was about to “go live” and Eduardo asked if the site is “finished”. Mark shot back, “It’s never going to be finished. Facebook is like fashion. It never ends.”

[read more...]