A few years ago, if you told me I'd spend most of my working day talking to AI agents instead of writing code, I would have laughed. I've spent 10 years building software, from React Native apps to SDKs used at enormous scale, and eventually leading engineering teams and departments.
I loved the craft. Expressive code. Elegant architecture. A beautiful component. Good tests. Even occasionally spending half a day figuring out why something worked perfectly on iOS and mysteriously broke on Android.
Like that ridiculous MyWheels bug where input text became invisible for some Android users with dark mode enabled. Same code, same device: perfectly fine in development, broken in the signed production build. Lovely.
Now I'm an indie developer again. In my previous post about missing the pixels, I wrote about how much I missed making things. The irony? I'm making things again, but AI does most of the actual typing.
I barely write code myself anymore. And you know what? I'm mostly fine with that.
The fastest train to the wrong destination
Let's get 1 thing straight: I love AI-assisted development. Cryptic build errors? Please, be my guest. Tedious migrations, boilerplate, dependency conflicts? Have fun. Some of that work was genuinely Sisyphean. I'm delighted not to do it manually anymore.
But AI is an incredibly fast train. Unfortunately, it doesn't always know where you're trying to go. And you don't want to end up in the wrong place at the wrong time (Some sketchy neighborhood across town, either east, west, north or south - it depends on your city). The train was fast, though. Congrats.
You ask an agent to implement something. It charges ahead: files change, dependencies appear, tests pass. 45 minutes and a mountain of tokens later, it turns out you've built on the wrong database model or introduced an abstraction nobody needed. It works. Technically. But you're traveling in the opposite direction and now you have to undo the whole journey.
Speed is wonderful. Direction is rather important, too.
5 hours saved. 5 hours reviewing?
Gergely Orosz of The Pragmatic Engineer has explored an uncomfortable question: are coding agents always making teams more productive? More pull requests can mean more code to review, more integration work, and sometimes more problems in production. Output isn't the same as value.
Here's the question I keep coming back to: did we just save 5 hours of coding, or create 5 hours of reviewing? Someone still needs to understand the changes, validate them, and maintain the system 6 months later when nobody remembers what that agent was thinking.
Sure, have another agent review the 1st one. Then 1 to review the review. Before you know it, you've recreated an entire engineering department in your terminal. Congratulations, you've reinvented middle management.
And what about cost? Are we eliminating work, or moving the bottleneck to tokens, reviews, infrastructure, and technical debt? Sometimes one, sometimes the other. That doesn't make AI a bad investment. It makes uncritical excitement a bad engineering practice.
We're becoming software makers
David Heinemeier Hansson, creator of Ruby on Rails, wrote Over My Dead Pencil about how little economic sense it now makes to write most code manually. He describes agents as something like new coworkers, and that's exactly how it feels to me.
I've led engineers for years. Today I direct astonishingly fast collaborators who never sleep and occasionally behave like new graduates who are extremely confident in their first idea. Some need considerably more babysitting than others.
I spent years advocating for developer happiness, expressive code, and elegant software. I still care. But am I going to spend 3 hours doing something an agent can reliably do in 3 minutes just to prove I'm a real programmer? Absolutely not.
I like DHH's term "software maker". I make software. Whether I typed every character is becoming less important. Whether the thing is actually good is another matter entirely.
The engineers who asked ‘why’ were onto something
Kent C. Dodds summed it up in You Own the Outcome:
Agents produce output. You own the outcome.
I've worked with brilliant engineers who could turn any ticket into working code. Input, output. I've also worked with the annoying ones who asked why the user needed that ticket in the first place. What problem are we solving? Do we have evidence? Would removing something be better than adding something?
The second group sometimes slowed the conversation down and saved us weeks of work. As implementation gets cheaper, those questions become more valuable, not less. I think we're becoming more like product engineers: understanding users, recognizing trade-offs, and caring about the result rather than celebrating a merged pull request.
To be clear, understanding a user doesn't magically replace technical fundamentals. It helps you decide when and how to apply them. You still need to know which decisions matter.
It works on my iPhone
Recently I was implementing a photo-sharing flow in one of my apps. The agent got it working on iOS. Lovely. But years of mobile engineering told me to ask the question it hadn't asked: what about Android share intents? I expected trouble. I tested it. And sure enough, Android behaved differently.
Nobody lost money. Nothing caught fire. But a founder without mobile experience might have shipped the feature because the agent said it was done. I didn't need to remember every API detail. I needed to recognize the missing question and make the agent prove its answer.
That's where 10 years of experience still pays off: not knowing every line, but knowing where the dragons tend to live.
“Make no mistakes. Make it secure. You're fired otherwise.” The prompt of the century.
I see prompts that sound like this: ‘Build me a feature in my app that will make me a millionaire, make no mistakes, make it secure, no fluffy language, and just do ittttt..’ Oh, excellent. Why didn't we think of telling human engineers that? Problem solved.
Telling an agent to make something secure isn't a security strategy. Telling it to write tests doesn't mean it understands what should be tested. I've seen plenty of beautifully green tests that simply verify a mock returns exactly what the test told it to return. Congratulations. You tested your mock.
Testing has always mattered to me. I was known in parts of the React Native community for my approach, and Expo invited me to write about building a solid test harness for Expo apps. I advocate for that even more now: test the important user journeys, the risky integrations, the actual failure modes. Give agents boundaries and a useful validation loop.
Thankfully the tools are catching up. Expo's agent-focused CLI helps agents work with the development environment instead of just producing files and hoping. I also regularly use Callstack's mobile-dev tooling for Codex. Giving agents the ability to inspect and validate a running app changes the game.
A successful build isn't the same thing as a successful feature.
Who's teaching the next generation?
There's one part of this shift that genuinely worries me: junior engineers. I learned by making mistakes, debugging impossible issues, reading documentation, and asking people who knew more than I did (is StackOverflow even still a thing these days?!). I was fortunate to learn from some of the best Dutch software engineers, including OGs like Vincent Hollander at Tranzer and Wouter de Vos at Codaisseur.
If agents now do much of the beginner work, how do new engineers develop the intuition to challenge them? I don't think juniors are doomed. But if we automate the apprenticeship, where do tomorrow's experienced engineers come from?
My advice would be to use AI to learn faster, not to skip learning. Break things. Understand networking, databases, security, state, and production failures. Learn to ask why. Otherwise you won't recognize when your very fast train has gone off course.
The bill might arrive 6 months later
I love seeing people without traditional coding backgrounds launch products through communities like Starter Story. More people can turn ideas into reality. That's wonderful. But I also wonder what happens after the demo works: when users arrive, when data grows, when a dependency breaks, when security isn't just another line in the prompt.
Not every indie app needs an architecture for millions of users. Overengineering is real, too. But choosing what not to build—and which risks to accept—requires judgment. At Stream, I worked on SDK technology used by products serving more than 2 billion end users. Those years taught me that working today isn't the same as staying healthy tomorrow.
Which brings me to a completely unofficial price list. It started as an old professional-services joke, and it feels suspiciously relevant to the agentic era.
That's the punchline: cheap implementation doesn't guarantee cheap ownership. Sometimes the invoice arrives much later.
Keeping my hands on the wheel
I'm somewhere between incredibly excited and mildly terrified. Part of me wants to put on diving gear, disappear underwater, and wait for this AI wave to pass. Except it won't. And I don't want to miss it.
As an indie developer I get to jump between user experience, architecture, backend, mobile, infrastructure, and testing. I feel like a product owner, designer, engineering lead, and software maker rolled into one. A rather busy octopus. Hence the octopus logo of stevegalili.com: a dozen responsibilities and somehow still not enough arms.
I love that freedom. But I don't want to lose control of the decisions that matter. Not every line of code; that would defeat the purpose. I mean control over direction, architecture, user experience, security, and what actually ships.
I use AI to move fast. But I bring 10 years of scaling, testing, and owning production systems so what we ship doesn't collapse later.
The code is cheap. The responsibility isn't.
I'm Steve, an independent software maker, former engineering manager, and longtime mobile engineer. I build with AI, experience, and a healthy amount of skepticism.