All Posts
February 8, 20263 min read

How a Small Team Actually Uses AI

Past the hype, here is what genuinely changed in our day-to-day building software for clients, where AI is a real multiplier, and where it quietly costs you more than it saves.

engineeringai

There is a lot of noise about AI and software development right now, most of it either breathless or dismissive. I run a software development company that ships real software for paying clients, so I get to see the unglamorous middle: where these tools genuinely help, and where they quietly cost you.

Here is the honest version, from inside the work.

Where it is a real multiplier

Some things changed for the better and are not going back.

  • Boilerplate and scaffolding. The first eighty percent of a CRUD endpoint, a form, a migration, a config file. Work that was never hard, only tedious, is now close to instant.
  • Getting into an unfamiliar codebase. Inheriting a client's legacy system used to mean days of archaeology. Now I can ask questions of the code and get oriented in an afternoon.
  • First drafts of the things people skip. Tests, documentation, commit messages, that README nobody wanted to write. A mediocre first draft you edit beats a blank page you avoid.

The common thread is that AI is strongest where the work is well understood and tedious, not where it is novel or load-bearing.

Where it quietly costs you

The failure modes are subtler than the wins, which is exactly why they are dangerous.

  • Confident wrong answers. AI will produce something that looks right, reads well, and is subtly broken. The cost is not the bug itself. It is that the bug arrives wearing a suit, so it gets less scrutiny than code a junior wrote by hand.
  • The review load moves, it does not disappear. Generating code is now cheap. Reading it, understanding it, and being willing to sign your name under it is not. Reviewing AI output is its own skill, and a team that generates faster than it can review is just accumulating debt with nicer formatting.
  • Juniors can stop learning. If the tool writes the code, the hard-won intuition that comes from struggling through a problem never forms. We are still working out how to get the speed without hollowing out how people grow.

How we use it without getting burned

The rules we have settled into are boring, which is the point.

  • AI writes the first draft. A human owns the result. Ownership is not negotiable; if your name is on the pull request, the AI's mistakes are your mistakes.
  • Never let it touch what you cannot review. If you do not understand the code well enough to catch it being wrong, you do not understand it well enough to ship it.
  • Use it to go faster on what you already know, not to fake knowing things you do not. It is an accelerator, and an accelerator pointed in the wrong direction just gets you to the wrong place sooner.

The part that actually matters

The teams getting the most out of AI are not the ones using it the most. They are the ones who know precisely where it helps and where it hurts, and have the discipline to keep it on one side of that line.

The tools got dramatically better. Judgment did not get any less important. If anything, it is the whole job now: the typing is cheap, and deciding what is correct is the part you are actually paid for.

PreviousWhy I am Building Lama