We spent this week moving every database we run into one managed home. Six projects, years of accumulated decisions, all of it consolidated. I expected the hard part to be the move.
The hard part was two characters.
The thing that broke everything
Connection settings usually come with a template. You copy a line, drop your password in, and go. The template marks the spot where your password belongs with angle brackets, like this: <your_password_here>.
The brackets are not part of the password. They are punctuation, telling you where to type.
I typed the password and left the brackets in.
Every application failed, all at once, with the same message: authentication failed. So I did what you do. I checked the password. Checked the username. Checked that the user had permission. Checked the network rules. Checked whether the new user had been created correctly at all. Each check took time, each one came back fine, and each one made the next theory more elaborate than the last.
The error was telling the truth about the symptom and nothing at all about the cause. That is the worst kind of error message, and it is extremely common. "Authentication failed" is accurate and useless. It cannot tell the difference between a wrong password, a locked account, and a password with two extra characters glued to the ends of it.
The second trap
While hunting for the first problem, we found a second one. The same setting had a different name in almost every project. Each name was reasonable when it was chosen. Together they were a trap, because setting the right value under the wrong name looks exactly like doing it correctly. Nothing complains. The dashboard shows a tidy list. The app just cannot see it.
There is no clever fix for that. We wrote the names down, in the place where the next person will actually look, which is the file they are already editing.
That is the whole lesson from the migration, honestly. When something bites you, the fix is not to remember harder. It is to put the warning where the next person will be standing when they need it. We added a line to every configuration template that says, in plain words, delete the brackets. It will look obvious to anyone reading it cold. It was not obvious at two in the morning with six things down.
Working with agents, which is nothing like how I used to code
This week was also my first real stretch using Claude Code, right after the company site launched. I have used AI tools for a long time. Working with an agent that runs commands, edits files, and pushes code is a different job.
Here is what actually changed.
I stopped writing most of the lines and started making most of the decisions. The work shifted from typing to judging. Is this the right approach, is this scoped correctly, does this match what we already do. That part got busier, not quieter.
Verification became the main skill. The single most valuable thing I did all week was ask short, boring questions. Is it actually pushed? Is it actually live? Did that test actually run? Not because the agent lies, but because a confident summary and a verified fact are different objects, and only one of them is worth anything. One time this week a push reported success and had moved nothing at all. We only caught it because someone asked.
Tests stopped being homework and became the referee. When you write every line yourself, tests confirm what you already believe. When work arrives faster than you can read it closely, the test suite is the one participant in the conversation that cannot be talked into agreeing with you. It either passes or it does not. I have never cared about a green check the way I care about it now.
The pace is genuinely different, and so is the failure mode. More shipped this week than any week before it. Also more verifying than any week before it. Those two things are not in tension. They are the same thing. Speed without verification is not speed, it is just a faster way to find out later.
What I would tell someone starting
Read the error message literally, then distrust what you assume it means. Put your hard-won warnings where someone will trip over them. Ask for proof, not summaries, and ask it about small things constantly rather than big things occasionally.
And check the brackets.
Gunnar
Founder, Tofte Ventures LLC