Building with AI
Anyone Can Build It Now. So Build It Well.
A couple of years ago, if you had an idea for a product, the first question was always: can we build it? Do we have the engineers, the time, the money?
That question is mostly gone now. My co-founder and I built a working finance app with AI tools in a few weeks. Onboarding, transactions, reporting, all of it. Things that used to take a team a quarter took us a sprint.
And I'm not special. Anyone with a laptop and a bit of patience can do this today. You can even look at a product you like, describe it to a model, and have a decent copy running by the weekend. That should make every founder a little uncomfortable.
If everyone can build, what's left?
When building gets cheap, building stops being the advantage. Your competitor has the same tools you do. So does the person who will clone you next month.
What's left is two things. How good the product actually is, and how well it solves a real problem for a real customer. That's it. Those are the differentiators now.
AI does give us one genuine gift here: speed to feedback. We can put something in front of customers in days instead of months and find out quickly if we're wrong. That's huge. But getting feedback faster doesn't mean much if what you ship is shaky. Fast and sloppy just gets you to the wrong answer sooner.
Quality used to hide inside people
Here's something we rarely said out loud. In the old way of building, a lot of quality was baked in before anyone wrote a test.
A good user researcher asked the awkward follow-up question. A good product manager pushed back on a vague requirement. A senior engineer looked at a design and said "this will hurt us in six months." None of that showed up in a QA report. It was just the quality of the people, quietly showing up in the work.
Now AI is taking over a big chunk of those stages. It drafts the spec, writes the code, generates the tests. That's fine. But the judgment that used to come for free with good people doesn't come for free anymore. If we don't put it there on purpose, it simply isn't there.
So wherever humans are still in the loop, their bar matters more than ever. And wherever AI is doing the work, we need to give it the context and the checks that a good person would have brought.
Quality has to move to the start
For most of software history, quality was something we checked at the end. Build the thing, hand it to QA, run the tests, fix what breaks. The earlier stages had quality too, but it lived in people's heads.
That model doesn't hold up when AI is doing half the work. A model will happily write clean-looking code for a requirement that was wrong from day one. By the time a test catches it, if it does, you've already built on top of it.
So quality has to shift left, all the way to the beginning. And it can't stop there. It has to be part of every step: design, product definition, coding, the code the LLM writes, deployment and end-to-end testing.
The stages stay the same. What changes is that each one gets checked, and each one draws on the same shared picture of the product.
Product, tech and GTM matter more, not less
There's a popular take that AI makes these roles smaller. I think it's the opposite.
When the typing gets automated, what's left is the thinking. Product people decide which problem is worth solving and what "solved" looks like. Engineers decide what good looks like in the system, and what must never break. Go-to-market people make sure the solution actually reaches the customer, in a way they understand and trust.
All three are now pointed at the same question: how do we get the right solution to the customer, and does it really solve their problem? The roles don't shrink. They get more focused, and the bar goes up.
Why we're building Adaptl
This is the problem Adaptl exists for. I learned it the hard way. Our app moved fast for the first month. By week eight I was afraid to change anything, not because the code was bad, but because I no longer understood what we had built.
What was missing wasn't more code. It was context. The customer feedback lived in one place, the errors in another, the design in Figma, and the reasons behind past decisions mostly in my head.
Adaptl pulls that together. It collects the signals around your product (what customers say, where they get stuck, what's breaking, why earlier decisions were made) and keeps them attached to the product itself. The more context we have, the better every step after it gets, whether a person or a model is doing the work.
Then it puts a quality check at each stage instead of one big gate at the end. Requirements get framed before anyone builds. Generated code gets checked against how your system is actually structured. Changes run in a staging environment with synthetic users walking through real journeys. Nothing goes to production until a human has seen it working and said yes.
The long game
In the short run, the teams that ship fastest will look like they're winning. In the long run, I think the winners will be the ones whose products still work, still make sense, and still solve the problem a year later.
AI made building cheap. It didn't make quality cheap. That part is still on us, and it starts much earlier than most of us are used to.
If you're building with AI and starting to feel that week-eight fear, I'd love to hear from you. We're working closely with a small group of founders right now at adaptl.ai.
Try your next change as your customers will
Adaptl previews every change your coding agent makes with realistic, made-up customers, so you can pin what's wrong before it merges.