I Was Right About the Wrong Thing

In January 2025 I wrote a post about AI coding tools. I reread it last week, which is a bit like finding a photo of yourself from a decade ago and realizing the haircut was a choice you made on purpose.

The post wasn't wrong, exactly. I said AI would take over the grind - the syntax, the boilerplate, the twenty minutes you spend figuring out which of the four ways to call a library is the one that doesn't throw. I said that would free developers up to focus on the actual problem. I ended with something upbeat about natural language coding interfaces being "on the horizon."

Well. The horizon showed up. It parked in the driveway and started eating out of the fridge.

All of that happened. It happened faster and more completely than I expected. And I still managed to be right about the wrong thing, because I framed the whole thing as a productivity story. Type less, ship more, everybody wins.

That was the easy half.

What actually happened

Here's the part I got right: the grind is gone. Not reduced. Gone. The CRUD work, the forms, the endpoints, the migration scripts, the fourth variation on a list view with filtering - that work is now hours instead of weeks. A developer who knows what they want can get it standing up before the coffee gets cold.

Here's the part I didn't think hard enough about: once you remove the thing that was taking up 60% of the calendar, whatever was taking up the other 40% becomes the whole job. And for most teams, that other 40% is figuring out what to build, for whom, and why.

Turns out we were never bottlenecked on typing.

We just couldn't see it, because typing took so long that it looked like the constraint. If a feature takes six weeks to build, nobody notices that the two days of thinking that preceded it were mostly vibes and a Jira ticket someone wrote in a hurry. The build time hid the sloppiness. It was a very effective disguise and it lasted about twenty years.

Now a vague ticket gets built in a day. Confidently. Beautifully. Completely wrong.

The uncomfortable part

I've spent most of my career hiring, promoting, and rewarding developers. If I'm honest about what we actually selected for, it was throughput and technical depth. Can you build the thing. Can you build it well. Can you build it without setting production on fire.

Those are real skills and they still matter. But almost nothing in that list was "can you tell when the thing shouldn't be built."

We didn't test for it in interviews. We didn't promote for it. In a lot of shops we actively discouraged it, because the engineer who pushed back on a requirement was the engineer who was slowing down the sprint. Ship it, we'll iterate.

So now the constraint has moved to a skill we never systematically built. That's not a people problem. That's a leadership problem, and it's mine.

What this looks like at Corfix

We build health and safety software for construction. Our users are not sitting at a desk. They're on a site, often in weather that Ottawa likes to describe as "character building," frequently wearing gloves, and they are trying to complete a form on a phone before they can get on with their actual job.

That context is the entire product. It's the difference between a feature people use and a feature people find a way around.

And here's the thing: you cannot get that context out of a ticket. You get it from watching someone use the thing. From a support call. From a customer telling you, with some heat, why the flow you were proud of doesn't survive contact with a job site.

So when the build time collapses, the constraint on my team isn't engineering capacity anymore. It's how many people on my team understand that job site. And that number was always smaller than it should have been, because everyone was busy building.

What I'm asking of the team now is different than what I asked in 2024. I'm asking developers to sit in on customer conversations. To be able to explain who a change is for before they open the editor. To be comfortable saying "I built this in an afternoon and I think we shouldn't ship it." That last one is the hardest, and it's the one I care most about.

Product engineers, if you want the label. I'll get into what I actually mean by that later in the series, because the term is about six months away from being ruined by LinkedIn.

This isn't a demotion for anyone

Two things I want to be clear about, because both fears are real and both are reasonable.

To the developers: none of this means your technical depth stopped mattering. It means it stopped being sufficient. Somebody still has to know why the system behaves the way it does, what the AI just generated, and whether it's going to fall over at 300 concurrent users on a Monday morning. I wrote a whole post about how wrestling with ugly legacy systems is what teaches you the business. That's more true now, not less. The difference is that the excavating and the judgment are now the visible part of the job instead of the invisible part.

To the product folks: engineers doing discovery is not engineers taking your job. It's the opposite. When five people understand the customer instead of one, the person who owns the why has leverage they never had before. What changes is that you can't be the only conduit anymore, and honestly, you never wanted to be. That relationship is worth a full post of its own and it's coming.

Where this series is going

I've got a list. Over the next few months I'm going to work through it, and I'm going to write about what we're actually doing at Corfix rather than what a nice framework would suggest we do. Some of it will be things that worked. Some of it will be things that didn't, which are usually the more useful posts anyway.

Roughly:

• What a Product Engineer actually is, in terms of what changes on Monday morning
• How you interview for this, given that our loops are still shaped like it's 2019
• The junior developer problem, which is the one that keeps me up at night
• Who owns the problem when engineering does discovery
• Why a vague spec is now a throughput issue, not just a planning one
• What happens to a quarterly roadmap when a feature takes two days

That's the plan. Plans change.

The correction

If I could edit that January 2025 post, I'd change one line. I wrote that AI tools let us "focus on what matters."

They don't. They remove the excuse not to.

The focusing part is still work. It's a different kind of work than most of us were trained for, it's harder to measure, and nobody's going to hand you a benchmark showing you got 40% better at it this quarter. But it's the job now.

Might as well get good at it.