Every design team I’ve worked with has had the same complaint about clients.
“They sent over a PowerPoint with mockups.” Eye rolls. Crossed arms. The unspoken accusation: you’re stepping on my domain.
I got it. The client would shortcut the process. Fall in love with their own wireframes. Hand the designer a solution instead of a problem.
That friction was real.
But here’s what nobody said out loud… the designers were doing the same thing to the developers.
A designer would disappear for a few weeks. Come back with approved comps. Hand them off to a dev team with zero context on the constraints they’d just inherited. The developers would look at the designs and realize that one “simple” interaction was going to blow the budget.
But the client already signed off. The battle wasn’t worth the effort.
So the devs would swallow it. Build it. Ask to be looped in earlier next time.
Next time, they’d ask again.
Nobody was tracking any of this
Here’s what we glossed over in all of that role-boundary drama… every person in every one of those conversations costs money.
Which developers sit in ideation meetings? Which designers join the earliest planning calls? How much does all that collaboration cost before anyone builds anything?
Debate has a dollar amount. So does prototyping. So does the politics of navigating who gets a voice and when.
That overhead was always part of the model. We just built it into the timeline and called it process.
The client just got a promotion
Now look at what happened.
That client who used to send over clumsy PowerPoint mockups? They can prototype at a fidelity that would have required a designer and a developer just a few years ago. They can ideate. Get feedback. Iterate. Evolve their thinking… before they ever pick up the phone to call someone like me.
All of those “my role is very critical” layers? Easy to gloss over when someone can test an idea faster than it used to take to schedule the kickoff meeting.
I’m not going to pretend that doesn’t threaten my business model. My entire consultancy is built around being involved in the strategy and implementation of those types of client ideas.
Despite that… I don’t blame people for wanting to see what they can accomplish on their own.
I’ve seen this movie before
In the late ’90s and early 2000s, some entrepreneurial founder would build an elaborate system in Microsoft Access or FileMaker Pro.
And it worked. It actually worked.
They ran meaningful parts of their business on something they stitched together with enough technical curiosity and sheer stubbornness to pull it off.
Here’s the thing people in our industry like to gloss over… a lot of those systems are still running. In production. Right now. Doing the thing they were built to do.
Sometimes because the system genuinely still meets the need. Sometimes because the person who built it never quite saw the value in investing in something nicer for the team of people required to interface with it every day.
We literally just replaced an Access-based system this past year with a Rails app. Not because Access stopped working. Because someone finally retired and nobody else wanted to own the damn thing they’d built several decades ago. I’ve written about that pattern before. It never stops showing up.
Eventually, some of those systems hit walls. They got complicated. Organizations needed real UX. Architecture. Scaling. Integration. Tech support. Operational resilience.
So they brought in people like us.
Those DIY systems birthed a whole industry. Our industry. Much of what we’ve built our careers on exists because someone who was dangerously just-enough motivated built something with the tools available to them.
I don’t know if we need all of those same steps now. The ceiling is a lot higher than FileMaker ever was.
But the pattern feels familiar.
I want to be careful here… because I hear people raising real concerns about AI and I don’t think those concerns are silly.
Quality. Accountability. Labor displacement. Environmental cost. The question of whether we’re building on a foundation that exploits creative work without consent.
These are legitimate things to wrestle with.
I’ve had to wrestle with versions of that question my entire career. And I mean my entire career.
When I was an employee, someone else was making those calls. I didn’t control the tools. I didn’t choose the clients. I just had to decide whether the work was worth the compromise.
There was a whole period where I was being asked to work with Micro$oft tooling and all I wanted was open source. Microsoft was the evil monopoly of the era. That wasn’t a casual opinion. It was a real position, held by a lot of people I respected.
I eventually quit that job specifically to go work with open source tooling. I genuinely believed it was better for small businesses. And in a weird way, I still think I was right about that.
Open source was built mostly by volunteers and contributors to a movement.
But now we have tooling that can leverage all of that work… and it feels like it’s at odds with what that movement stood for. There’s a part of me that wonders if I’ve ended up on the wrong side of this one. Whether I’m advocating for the dark side and just can’t see it from where I’m standing.
But then I think about open source a little more honestly. Were we not heavily borrowing on the ideas of commercial products the whole time? “Open source clone of Microsoft Project” was a real search term. So was “open source version of Oracle.” Legitimate things people were actively building toward. Open source didn’t emerge from a vacuum. It emerged partly in opposition to commercial software, sure. But also in imitation of it.
The ethical lines were blurry then too. I just wasn’t paying close enough attention to notice. I’m not smart enough to have that philosophical debate now. I definitely wasn’t back then.
I’ve worked with clients whose labor practices abroad I used to actively protest. Built software for companies that produce products I would never put in my body. Worked with organizations that preach things I don’t believe in and don’t support.
Because there was an exchange of services rendered. Because I had a team to feed.
Because the alternative was… what, exactly? Holding out for clients whose values perfectly aligned with mine on every axis?
That’s a nice story to tell yourself at twenty. It’s also bullshit if you’re trying to make payroll.
Twenty-year-old Robby would have called me a sellout.
Forty-six-year-old Robby is a little more open to the idea that you can do meaningful work within systems you didn’t design and don’t fully endorse. That the money I earn lets me invest in things I actually care about. That the good I can do with the work produced matters alongside the work itself.
This isn’t unique to software. Every carpenter, every accountant, every nurse has had some version of this negotiation with modern capitalism. It’s a matter of what good you can do with the resources you earn.
Not a clean equation. Never has been.
Full disclosure
I should be honest about something. Six months ago, I was closer to the skeptics than I’d like to admit.
In January, I wrote about humans in the loop after the Oh My Zsh team spent real time figuring out how to handle AI-assisted contributions. We weren’t anti-AI. But we were grappling with the cost of reviewing work that looked plausible without being deeply understood.
That’s a legitimate concern. It still is.
A few weeks later, I wrote something more personal: I Didn’t Want AI to Be Good at This. The title says it all. I was coming around begrudgingly. I didn’t want the calculus to change.
But it changed anyway.
I’m still adjusting. I don’t have this figured out. I’m just further along than I was in January.
The job description changed
I’m hearing firsthand from peers who run small software teams. They’ve got engineers who aren’t just reluctant about AI. They’re not cautiously skeptical. They are entirely, firmly against it.
“Am I being forced to adopt this, or do I need to go somewhere else?”
That’s not a hypothetical. That’s a real conversation happening between developers and their managers at real companies. It’s being discussed in leadership meetings by people trying to figure out how to catch up with adoption. Some of those companies are also struggling to keep the business afloat right now.
And honestly? A lot of us were hired to write code. That’s not revisionist. That was the job description. We were brought in to produce code the same way a writer is brought in to produce words.
And let’s fact-check ourselves for just a moment here… because I can already picture people reading this and thinking they disagree.
We asked candidates for coding samples. We put them through live coding exercises. We talked about coding standards. Style guides. Naming conventions. We’ve all wished for… and sometimes had… the chance to reject someone’s code because it didn’t meet our conventions. Didn’t match our writing style.
Writing style.
Let’s not kid ourselves that we were entirely hiring for “outcomes” all along. We built the whole hiring apparatus around the artifact. Whether that was framed right or not… that’s what we did.
The codebase doesn’t care how it got written. It cares whether it works, whether it can be maintained, and whether it helps the business do what it needs to do.
That’s not a bait and switch. That’s what happens when your organization gets access to new tools and the economics shift underneath everyone’s feet.
What we have now is a training problem. A reclassification problem. And I’m not sure what the best HR-friendly way to frame this is… but here’s a serious question:
Would you rather your company post a new job ad for what they actually need going forward and let you compete with people from the outside? Or would you rather have the insider track to try out the evolving role before you decide to move on to some idealized version of what you were originally hired to do?
That’s not rhetorical. I think teams need to commit to a course of action here. If there are new roles to be defined… define them. Post the ad. Phase out what’s no longer needed as originally written.
Because “overseeing agents on my laptop produce code wasn’t on my job description” is going to be an exhausting fucking conversation for every human involved.
Most of us at smaller companies don’t have much of a voice in the big industry narrative. We’re not fielding hundreds of inbound inquiries and cherry-picking dream clients. We service the clients we can attract.
If you think now is the right time to turn away work because you disagree with whether AI-generated code is ethical… I understand the impulse. I do.
But I also think you might be asking the wrong people the wrong question.
What you might need to be asking is whether you need to find a different industry entirely.
Or… maybe you brand yourself as an artisanal coder. Find the organizations actively resisting LLM adoption. Carve out that niche.
I think that path can work for an individual. I’m skeptical it can sustain a company for long.
I don’t know what my own success looks like in five years. I don’t think anyone does.
It’s kind of scary. Nobody is going to tell you otherwise with a straight face.
But I know that the people who thrived after the FileMaker era weren’t the ones who resented the founders for building those systems. They were the ones who understood why the founders built them… respected what they accomplished… and then made the case for what comes next.
