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 the principles behind building. Each one is a reminder that while the technology changes quickly, the questions that matter often stay the same.
--
Dear past Jenna,
The thing that drew you to tech in the first place, that it's always changing, is the thing that will keep you here.
Tools change (sometimes for the better and sometimes not) almost weekly. People who never consider themselves technical, much less a developer, will build apps in an afternoon with this new programming language called English. Products will go from idea to deployed before you finish your first cup of coffee (you have a toddler now, so you rarely get the full cup before it goes cold anyways). "I don't know how to code" or "I'm not technical" is no longer a barrier to building.
And that's exciting, given you've focused nearly your entire career helping others build software. But we can't confuse the ability to build with the wisdom to build.
One of the most valuable habits you've developed over the last two decades is asking a simple question:
"Should we build it?"
For most of your career, "Can we build it?" was a hard question. Time, budget, complexity, maybe the tech wasn't there yet. But those constraints were usually temporary. With enough people, time, and money, just about anything is possible. But the real questions were always: Should we build this? Is this the best use of our time? Does this solve a problem our customers actually need solved, or does it create new problems? What are we choosing not to build?
Those questions haven't changed, but the environment around them has.
Today, almost anyone can build software. Between tools like Lovable, Bolt, Replit, Claude Code, Codex, and whatever's next, the barrier to building software is lower than it's ever been. Now the question "Can we build it?" is too easy to answer. It's almost always yes, and so we build. That question and the friction of it has disappeared. It no longer helps us decide what deserves to be built.
We build because it will only take 15 minutes. We build because we can come back to iterate on it later. We build because we're curious. We experiment. And experimenting has always had a funny way of becoming production. That internal tool for your team? Someone depends on it now. Ope. Now it's open source, too. That weekend project you made for your kids' soccer team? It needs updates after the latest API changes. That AI-generated app you made for yourself? Congrats! You are now its lifetime maintainer.
Software has always been easier to create than to maintain. Remember those sprints spent getting tests working again? To fix security vulnerabilities introduced by dependencies? Remember that penny you chased across systems because a tax calculator service got swapped out and surfaced a whole bunch of rounding errors? We accepted those costs because engineering resources were scarce. This scarcity wasn't always bad. It forced us to ask the more important questions, like what deserved to exist.
AI made it dramatically easier to create software. And every new app, feature, script, internal tool, or even weekend project becomes someone's responsibility. But now we've removed much of the friction that made us pause before creating it, friction that forces us to ask these important questions.
And since it's easier to create, software starts looking the same. When we all have access to the same models, tools, and building blocks, it's easy to build software that's just like everyone else's.
This doesn't mean we stop building! But it does mean the bar has moved.
Now the differentiator is whether you saw something others didn't. Whether you deeply understood the customer and their problem. Whether you removed the unnecessary instead of adding yet another feature. Whether you solved a problem worth solving instead of simply proving you could.
Code was never the differentiator. Looking back, the best engineers I've worked with were remembered because they knew which problems were worth solving in the first place.
You'll also find yourself asking a related question more often (and not just about what you're building but what others are building): "Should this exist at all?" That's a letter for another day.
You'll be tempted to celebrate how quickly you can build. And you should. But don't let the ease of building lower your standards for what deserves to exist. As the answer to "can we build it?" becomes an easier question to answer, raise your standards for answering "should we build it?" just as quickly.
Until the next postcard.
Top comments (34)
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.