I've spent my career helping people build software. This is a series of letters about what happens when the tools for building change faster than t...
For further actions, you may consider blocking this person and/or reporting abuse
I think this is REALLY important. Although we have the tools to build projects faster, it doesn't mean software becomes advance. It's whether you still have the ability to solve problems and using the tools to do so.
A lot of projects out there are similar to one another because they worry about standing out from the crowd and worry about if the project "looks nice". I think the question we should ask is: Can you explain why you build it?
Great write up Jenna!
Thank you!
Yes, in the before times, I know a lot of projects weren't even started because we worried they wouldn't stand out or look "nice" enough. And now we have less holding us back. Love the question "Can you explain why you build it?"
This strongly resonates with me.
AI tools have dramatically reduced the effort required to turn an idea into working software. I can now build in days what previously might have taken weeks. But while building with them, I often find myself asking another question: “Do I actually understand what I’m writing?”
Sometimes the implementation moves faster than my own understanding of the system. I may know what I asked for and see that it works, but can I explain the important decisions, debug it without the AI, and confidently maintain it later?
Before AI coding tools, struggling through architecture decisions, bugs, and trade-offs helped me develop judgment. Now the implementation friction is lower, but the responsibility is greater. We need to be more deliberate not only about whether a problem is worth solving, but also about whether we truly understand and own what gets built.
Perhaps the most important engineering skill in the AI era is no longer producing more code, but deciding what not to build—and making sure we can still explain, maintain, and take responsibility for what we do build.
You mentioned something important about understanding the system. After getting deep into vibing I've been asking myself (vibe engineer) 😉 - what if you no longer have access to assistants 🤷,
That thought pushes me to deeper work than the surface vibing now I want to understand what my code does literally not hopeless when an assistant is unavailable. Debugging lately feels less stressful & I'm always learning ✌️
Completely agree. We've noticed something similar while building Failproof AI. It's becoming easier to generate software than to confidently explain why it behaves the way it does. Understanding, validating, and owning runtime behavior feels like the new bottleneck, not writing the code itself
In as much as the barrier is lower, someone actually said to me recently: 'Everyone now builds software for themselves. Build for yourself because no one needs programmers anymore when they have AI coding assistants.'
I drew some real sense from that energy—not as a negative, but as a realization far deeper than what books or tutorials teach. The takeaway for me wasn't the rejection, but the shift: experience what you build. Since then, I consider user experience more than just assembling code. Just like you said: 'Does it solve a problem?'—not just building because you can.
Nice read! 💕
Hey thanks for reading!
Agree. Even when we build for ourselves we can ask the same questions. It might just be that the answer is to learn something more deeply or to experience it like you said.
The scariest part is that people seem to lower their expectations for quality, getting used to the overflow of low-quality generated content.
It's so overwhelming too 🫠
I’ve been thinking about the whole 'Will AI replace software developers?' debate using a simple analogy: mechanics.
These days, many people use AI to diagnose and fix basic issues with their cars or motorbikes. Does that mean professional mechanics are obsolete? Of course not.
In fact, this shift is a sign of progress. Think about the early days of the web: companies had to hire specialized developers just to build a basic website. Today, drag-and-drop tools allow anyone to build their own site, which frees professional developers to focus on much deeper, complex architecture.
The same thing is happening with software engineering. When non-developers use AI to build or fix simple things, it offloads the 'routine' work so experts can concentrate on high-impact problems.
More importantly, how you use the tool matters. While anyone can ask AI to solve a problem, an experienced engineer uses AI with a depth of domain knowledge that a non-developer simply doesn’t have. We aren't being replaced, our role is evolving to a higher level.
So... yes build it!
Yes, exactly!
Yeah, this is basically the thing I keep bumping into with trimy.io. Building isn't the bottleneck anymore, it's barely a speed bump. I can ship something in an afternoon that used to take a sprint. The problem is nobody warns you that "I could build this" and "I should build this" feel exactly the same in the moment, it's only six months later, when you're the one maintaining the thing nobody asked for, that the difference shows up.
The hardest no's for me haven't been features, they've been my own ideas, easiest thing in the world to talk yourself into building something because you can.
How do you catch yourself before you build the wrong thing, is it a rule you follow, or does it usually take someone else telling you to stop?
Haha! I've definitely been told to stop something. But I think I just built some of these questions into my work processes really early so they are habit now. I worked with people who held me (and our teams) accountable for making sure we're solving the right problem at the right time... which requires all these questions to be asked.
That's smart, turning it into a habit instead of relying on willpower. Makes sense it sticks faster when other people are asking the same question with you, not just you alone.
I'm getting there too, just slower, mine came more from maintaining stuff I regretted building than from a process.
This hit uncomfortably close to home, Jenna—especially that line about the weekend project becoming a lifetime maintainer. I have a folder full of those, and I swear each one has a tiny ghost living in it that wakes up every time a dependency updates.
What really stuck with me is how you flipped the scarcity argument on its head. We used to think limited resources were a bottleneck, but you are right—they were actually a filter. They forced us to sit with the discomfort of saying "no." Now that AI removes that discomfort, I wonder if we need to invent a new kind of artificial friction on purpose. Something like a mandatory "sunset clause" before we even start building: define upfront what success looks like and what decommissioning looks like, so we are explicitly giving ourselves permission to kill it later without guilt. That might sound unglamorous, but I think it is becoming a survival skill.
Also, your point about software all starting to look the same made me think—maybe the real differentiator going forward is not just solving the right problem, but consciously choosing not to build something that everyone else is building. There is a quiet power in looking at a trendy AI-generated tool and saying, "Actually, our customers do not need that, they need this weird manual workflow we observed them doing at 2 AM." That kind of human context is still completely invisible to the models, and I hope we protect it fiercely.
This letter honestly feels like required reading for every product manager and junior dev I know. Thank you for writing it.
I saw an article somewhere (maybe on LinkedIn?) whose main point was something like this:
Yes, with AI we could probably build something like Booking.com in a day. Sure, the architecture might be closer to a trash bin than a masterpiece, but we could build it. What we can't build in a day is a successful company.
The reason is simple: there's much more to building a successful product than writing code. Code has always been the last step.
First, you need to solve a real problem, not invent one just because your app doesn't fit anywhere else. Nowadays, there's already an app for almost everything, and most of these AI companies is just a fancy wrapper for chatgpt, that just burns money.
Second, we build products for people. If people don't like them or don't find them useful, then we haven't really solved anything. We've just occupied a few more megabytes in the cloud. If we can solve almost anything in a day, why NO app is accessible.
AI has made building software incredibly fast, that's true. It hasn't made understanding customers, validating ideas, earning trust, or creating products people genuinely love any easier.
Very much agree on this!
Love your framing as sending to your past self. You are spot on - like yourself, I have been in endless debates on "should we build it", alignment with broader goals, blah, blah and killed many ideas or scoped down or scope changes leading to many debates, some heartaches and so on - and not a single line of code was probably written towards that initiative. As you said, AI has enabled us for rapid prototyping and now in my organization, discussions are shifting from discussions aided by ppt, word docs, GIST idea tickets, memos to "tada! see I built this, can we ship this?". Plus side is, many wordy documents with mocks have not been able to convey what a working prototype has managed to do. Prototypes built in a hustle comes with its own issues as now the debates are shifting to - will it scale, will it be secure, how do we build on top of this. At this point - the answer seems to range from "I really don't know Claude or Cursor wrote it, all I have is prompt" to "Yes, I have a spec that I can extend and I have considered scaling, auth, integration etc." The former answer is more common though. Anyway, these are interesting times and as a leader embracing this, I have been shifting my playbook to allocating a budget for innovation + experimentation that does not burn down the business. I am reframing often as "show me a prototype with working code, but don't make it too elaborate. See what you can come up with 0.5 day, Go!"
Another thing I would add is the fatigue all this is creating... building is cheaper and faster, and there are so many new projects coming out that it is hard to focus on one, and it is also impacting projects that are actually good but are getting lost in the sea.
I strongly agree that understanding the requirements and needs is the most important part now; going deeply into the problem and solving it will win at the end. (or at least I hope so)
Anyways, great article, thank you for sharing!
For sure, it is more fatiguing. It's not just software and tools, but I see it with content too. Only so many blog posts I can read on the same topic without much difference.
You got the point! Tools exist because they're basically meant to solve problems whether they're big or not. Considering that, figuring out real pain point in lives would be the real moat.
This is such a thoughtful perspective. New AI tools lower the threshold of development dramatically, letting anyone quickly build technical products. But the core value of software development always lies in solving real business pain points, rather than simply stacking new technologies. No matter how fast tools iterate, the original logic of "whether we really need to build this system" is eternal.
Great job. This is a great way of framing the change AI is bringing to software development. When building becomes cheap (I still think its cheap, however many might disagree) and fast, judgment becomes much more valuable. The difficult part is no longer producing the code, but to maintain it afterward. “You can build it, but should you?” is a question I need to ask myself more often.
A clear article.
My English is poor.
No matter how much crap it is, I think so. If you're bored like me, go for it. Whether it's a pathetic clone of some website, app, or game, do it—just to bolster your skills, and new ideas often come along the way.
Mass availability != quality. Without technical skills, you'll pee your pants at the first compiler error.
Project development is a responsibility. That responsibility lies with the human. AI is simply your right hand, nothing more.
Therefore, due to easy access and a low barrier to entry, we're seeing some outright crap appear on the market that's impossible to get rid of. What's worse is when you build a business on it. On the cheap, when you don't even know what you're doing.
Words of wisdom.
I'd add that the bar has risen because things built mostly by AI now lack soul. Therefore, truly valuable applications are becoming increasingly rare. For example, the AI-powered UI is largely inconvenient, the algorithms are sometimes unoptimized, and the games are pure trash. Just try to find a truly heartfelt story in them, rather than cheap, donation-based garbage. Everything is driven by the desire for quick results. And money.
The same shift from "can" to "should" is playing out in professional networking right now. We can connect with thousands of people with one click, but that ease makes us skip the harder question: which of those connections is actually worth the time? A big contact list is just a display. The real asset is knowing which five people in your network are relevant to what you need this month, without manually scanning hundreds of profiles. The friction of manual filtering was never the problem. It was the only mechanism forcing us to be intentional. When that friction disappears, intentionality has to be designed in from the start.
I agree. The value is moving away from implementation speed and toward decision quality. AI can help build almost anything, but it can't tell you whether the feature solves the right problem or whether the resulting system will behave reliably in production. Those still require engineering judgment
This framing really resonates. There's something almost paradoxical about how the faster the tools evolve, the more the fundamentals matter. When everyone has access to the same powerful tools, what differentiates good software from bad software becomes less about syntax and more about judgment knowing what to build, why, and what tradeoffs you're making. Looking forward to this series.
This whole thread assumes you get to decide. I don't, most of the time.
Freelancer in Indonesia, small business clients. When someone asks me to build
something that shouldn't exist — a feature they saw a competitor use, an app
that duplicates what their WhatsApp group already does fine — "should we build
it" isn't wisdom I get to apply. It's me deciding whether I can afford to talk
myself out of a paying job this month.
I've done it both ways. Talked a client out of a mobile app they didn't need,
and they went to someone else who built it. Also built things I knew were
pointless because rent existed. Neither felt good.
What did change things for me is the maintenance part you mention, but from the
other side: I stopped being the lifetime maintainer by default. Now the handover
doc and a fixed support window are in the contract from the start. It doesn't
stop the wrong thing getting built, but at least the wrong thing stops being
mine forever.
Curious whether you think "should we build it" survives contact with people who
need the work. Or whether it's a question that only exists once you have enough
leverage to ask it.
I understand where you're coming from and I've been in those situations too, doing it because I need the money and talking them out of it. But I think there's a third option here, which is instead of talking them out of the wrong thing, talk them into the right thing. If it's not reinventing What's App, then what is it? Ask questions around what actual problem they are trying to solve. You might have to ask multiple times in multiple ways to get to the root issue they are trying to solve, but only then can you figure out what the right solution is. It won't work every time, but for the right projects, it will.
I also think this is behavior that moves us away from just being a programmer that takes direction and toward a role that provides input into the business, the product, and the engineering work.
"Raise your standards for answering 'should we build it?'" is right, and I want to report from the far end of it: I've answered that question a few dozen times in a row, badly, and then had to live in the results.
I'm a physical therapist who builds internal tools with AI. Over a year that turned into a few dozen of them, all in production, all mine to maintain. Every one passed the "should we build it" test at the moment I asked — there was a real person doing a real thing on paper, and now they aren't. What I didn't have was any way to weigh what I was signing up for on the other side, because I'd never maintained anything. The build cost was visible and small. The custody cost was invisible and permanent, and it only becomes legible after the first tool breaks in a way you didn't design for.
Which is why I'd put the missing piece as: judgment about "should" is downstream of having maintained something. Not built — maintained. The instinct that makes you hesitate isn't knowledge about the problem space, it's the memory of being paged for something you shipped a year ago. AI shortened the build loop to hours while leaving the feedback loop at its old length of months, so the very experience that produces the judgment you're asking for now arrives long after the decisions that needed it. For people entering this way, "raise your standards" is correct but unactionable on its own — the standard has to come from somewhere, and for most of us the only available teacher is the thing we already shipped and now can't put down.
This resonates deeply. The "build friction" that used to force us to think through whether something was worth building has essentially vanished.
One pattern I have found useful is a lightweight "maintenance budget" check before any new build: who will maintain this in 6 months, and do they have the capacity? If the answer is nobody or the person who built it in a spare afternoon, that is a red flag — not against building it, but against letting it escape into production dependency.
The part about experiments becoming production is painfully accurate. I have seen internal tools built in a weekend become load-bearing infrastructure within a month, with no tests, no monitoring, and the original builder having moved on. The irony is that AI makes this cycle faster: you can go from idea to someone depends on this in days instead of weeks.
The question is not just should we build it anymore — it is can we afford not to maintain it? That is the real cost question most teams skip.
"The ability to build versus the wisdom to build" is the line I want to pin above my desk. The cheaper building gets, the more the actual constraint becomes judgment about what deserves to exist, and that skill doesn't scale with the tooling. How do you personally decide when something is worth building versus when the answer is just no?
The scarcity point deserves more credit than it usually gets. It wasn't just that resources were limited — it's that requesting them put a human in the loop who asked why. Someone had to justify the work to a person who could say no, and half the bad ideas died in that conversation rather than in review. When one person can ship in an afternoon without asking anyone, that filter is gone entirely, and nothing has replaced it. The cost doesn't show up for two years either: it shows up as the dependency that won't upgrade, the auth flow nobody remembers writing, and the person who built it having left. Building was never the expensive part.