I'm a product leader, not an engineer. I have no formal training in software development. I can't explain how a database index works or what a reverse proxy does.
Last year, I built a functional satellite monitoring module in nine days using AI tools. It pulled real data, ran real calculations, sent real alerts. A risk analyst at a client company used it daily for weeks. The code would make any backend engineer wince. The architecture was naive. The error handling was "it crashes and you refresh."
But it worked. And the feedback from that crude, ugly, functional module was better than months of specification and design would have produced.
I'm telling you this not to brag about building bad software. I'm telling you because this is happening everywhere, and it changes what engineering means.
The translation step is disappearing
For 30 years, a huge part of engineering work has been translation. A PM writes a spec. A designer creates screens. An engineer reads both and turns them into code. The engineer interprets someone else's description of what to build, fills in the gaps the documents didn't cover, and makes dozens of micro-decisions that nobody anticipated.
I've talked to engineers who describe this experience with surprising candor. "I spend half my time figuring out what the PM actually meant." "The spec says X but the user clearly needs Y, and I can't change it without a three-meeting process." "I'm building features I don't believe in, but nobody asked me."
AI tools are automating exactly this translation step. The structured transformation of "description in, code out" is the kind of work that AI handles well. Not perfectly. Not at production quality. But well enough that a non-engineer can produce something functional.
This means the engineer whose primary contribution is translating specs into code is in a vulnerable position. Not because that work is unimportant. Because that work is increasingly automatable.
What becomes more valuable
Here's the thing that most "AI will replace developers" takes miss: when non-engineers can build functional prototypes, engineering doesn't shrink. It refocuses. And the refocused version of the job is harder and more interesting.
On my team, engineers now enter when there's a validated product that needs to scale. The prototype works but the code is messy. The architecture needs to be rebuilt for production. Security needs to be implemented properly. Performance needs to be optimized. Integration with the core platform needs to be designed. Data models need to be restructured for real scale.
This is harder work than translating a spec. The engineer isn't implementing someone else's vision. They're taking something that provably works and making it robust, scalable, and secure. They're solving real engineering problems, not implementation puzzles.
And they enter with something engineers rarely had before: complete context. They can use the prototype. They can see the user data. They can read the feedback. They understand not just what to build but why it matters and how people actually use it.
The engineering lead on my team told me, after receiving his first prototype-based handover, that it was the best brief he'd ever gotten. Not because the code was good. The code was terrible. But because he could see the product working, understand the user's behavior, and make architectural decisions grounded in real usage patterns instead of speculative requirements.
The handover changes
In the old model, engineering received documents. A spec, designs, acceptance criteria. The engineer's first task was "read the spec and ask questions."
In the new model, engineering receives a working product. A Git repository with messy but functional code, a list of known issues and limitations, real user feedback, usage data from the alpha, and a clear recommendation on integration path.
The engineer's first task is "use the product, look at the code, and tell us what needs to change for production." That's a fundamentally different starting point. It's grounded in reality, not in someone's written description of reality.
The convergence nobody talks about
The line between product and engineering is blurring from both sides. Product people are learning to build using AI tools. But the convergence runs the other direction too.
When anyone can build, the differentiator isn't building skill. It's knowing what's worth building. And knowing what's worth building requires understanding the business, the user, and the market. That was traditionally the product person's domain.
The engineer who can look at a prototype and say "this is solving the wrong problem" is more valuable than the engineer who can optimize code that nobody uses. Technical depth remains essential. Business context makes it impactful.
The "pure dev" role won't disappear, but it will narrow to the hardest problems. Scale, security, infrastructure, developer tooling, complex integrations. This work is essential, and the people who do it well will be more valued, not less. But it's a smaller percentage of what "engineering" currently means.
The common frontend, backend, or QA role will converge toward the business and value generation pipeline. Not because those engineers will stop writing code, but because writing code alone won't be enough.
The spreadsheet analogy
Spreadsheets didn't kill accountants. But they made financial modeling a horizontal skill. The business person who used to wait for the finance team to model a scenario could suddenly do it directly. The specialist didn't disappear. The dependency did. The specialist shifted to more complex, higher-value work.
AI building tools are doing the same for software construction. The product person who used to wait for the engineering team to test an idea can now build a functional version directly. The engineer doesn't disappear. The dependency does. The engineer shifts to more complex, higher-value work.
The question is whether you see this as a threat or an opportunity. If your value is in translating specs into code, it's a threat. If your value is in architecture, scale, security, performance, and deep technical judgment, it's an opportunity. Because the demand for that kind of work isn't going away. If anything, it's growing, because more ideas are being validated and more products need to be scaled.
What I'd want engineers to know
I'm writing this as someone who builds with AI tools and relies on engineers to make it real. A few things I've learned from being on the other side:
The code I produce is bad. I know it's bad. I'm not trying to do your job. I'm trying to learn whether an idea works before asking you to invest weeks making it production-ready. When I hand you a messy prototype with real users, it's not disrespect for your craft. It's respect for your time. I'd rather give you something validated and ugly than something speculative and well-documented.
The engineers on my team who embraced this model are doing the most interesting work of their careers. They're making architectural decisions grounded in real usage data. They're solving scale problems for products that users already depend on. They're not translating ambiguous specs. They're building real systems.
The engineers who resisted are struggling. Not because they lack skill. Because their value proposition was tied to a step in the process that's being automated. The ones who adapted redefined their value around the things AI can't do: judgment, architecture, security, scale, and the deep understanding of systems that comes from years of experience.
The shift is real. The question isn't whether it's happening. It's whether you position yourself on the side that becomes more valuable or the side that becomes automatable.
Discuss.
Top comments (1)
The line about knowing what's worth building as the new differentiator is crucial. Technical depth alone was never enough it was always paired with business context at the senior levels. Now that pairing starts earlier in everyone's career.