No, not everyone should code at work
Why the citizen developer dream is a management nightmare, and how to integrate technical governance with business agility.
If a developer spent half their day cold-calling prospects, you would fire them. Yet we now celebrate when sales reps spend their afternoons building custom databases? Something is backwards about that math, and generative AI is about to make it worse.
The Quick Version
The 2010s citizen-data-scientist push mostly failed because low-code tools never replaced real engineering discipline, and generative AI is now repeating that same mistake at scale.
Handing coding to non-technical staff drains selling time, fractures your single source of truth, and buries central IT under fragile, undocumented tools nobody can maintain.
There is a way to put real coding capability at the front lines without turning your staff into amateur programmers, and it starts with one structural move most companies get backwards.
We Tried This Ten Years Ago
Do you remember that craze about 10 years ago where everyone was saying, “Now everyone can be a data scientist! We can give them the tools to do it and we should.”
As with many things, just because you can, doesn’t mean that you should. I was in the maligned minority that didn’t think our head of sales or the director of operations should focus on data science rather than their stated job roles. They needed the end product, not to learn the process.
Although people like to focus on the exceptions, most of these initiatives to put data analysis in everyone’s hands failed because:
The tools were never as easy to use as vendors said.
Best practices were never established, so four people would show up in a meeting with different sales figures for Q1.
Costly tools were deployed on a seniority basis, but invariably it became one junior person’s job to actually do the work for their whole group.
Today, we are repeating the exact same mistake with generative AI.
It’s called the Citizen Developer. It is the idea that everyone in the company designs their own software.
Let’s not. There is a better way. And at the end I have what to say at your next management meeting.
The Hard Part Was Never The Typing
Why is the marketing department using an AI tool to do software engineering?
Writing a few sentences into a chat box is not software engineering. A real application requires a structural foundation that someone who doesn’t have the background simply cannot provide. This includes things like:
A database that does not fall over when 10 users search it at the same time.
A memory system that remembers who you are from page to page.
Clean safety nets so the app does not show users a screen of raw code when something goes wrong.
Saying that what most people create with AI is software does an extreme disservice to real software developers. It is like saying that because I have watched every episode of House, I am now qualified to perform open-heart surgery.
Software engineering is a discipline. It requires years to understand how to protect customer information and keep systems running during a traffic spike. When we tell non-technical employees they can build their own enterprise tools, we are setting them up for failure. We are pretending that the hard part of software is typing the words, when the hard part is the architecture.
What happens to productivity when everyone starts coding?
All the time your sales reps spend building local tools is time they are not spending selling. Marketers should market, salespeople should sell, operations people should operate. If a software engineer spent half their day cold-calling prospects, they would be fired immediately. Yet we celebrate when a sales manager spends 3 days building a custom database.
Worse, the job does not end when the tool is finished. Software requires maintenance. When the tool breaks, the sales manager has to stop selling to troubleshoot a broken link or a failing form.
If they get stuck, they call central IT. This pulls professional developers away from core projects to fix a hobbyist tool. Fixing that code is a massive waste of expensive engineering resources.
This lack of value is why so many mass-deployment AI efforts show so little revenue or margin impact.
A baker should focus on the perfect baguette, not on writing custom accounting software. The business loses velocity when employees get distracted by the novelty of building tools instead of using them.
Subscribe to keep reading
What are the dangers?
Letting everyone code introduces serious security and compliance risks. Most business users do not know the basics of data safety. They often make critical errors:
Leaving passwords and system keys visible in their text.
Storing sensitive customer data in plain text.
Ignoring privacy laws that protect customer data.
This is not a shadow IT problem where employees sneak in unapproved software they need. These tools are centrally mandated, procured, and paid for. The problem is that you end up with non-vetted, insecure data sources fragmenting your organization’s data layer.
When every department builds its own dashboards, you lose the single source of truth. Four managers show up to a board meeting with four different sales figures because they built their own calculations. You cannot run a business on amateur applications that lack audit logs and collapse under the slightest load.
What is the true cost of solution sprawl?
Solution sprawl is a financial drain. Since the preview launch of Databricks Apps, over 50,000 data and AI apps have been created, with usage up 250% in six months (Databricks figures reported by Forbes, February 2026).
But weak governance means dozens of teams build overlapping agents that consume expensive compute power. Cheap and easy to build today does not equal cheap and easy to own tomorrow.
Allowing every department to spin up bespoke tools creates a massive maintenance bill of working-but-unmaintainable code. Central IT is eventually forced to adopt and support these fragile, undocumented tools when the original builder moves on. That is how you build a mountain of technical debt.
Engineers Where The Work Happens
We do need coding closer to where the work is done. We need to capture and refine processes at the front lines and cut the time it takes to ship solutions. But the answer is not turning your entire staff into amateur programmers.
The answer is embedding professional software engineers directly inside your business units. These are Forward Deployed Engineers (FDEs).
An FDE is a professional developer who sits next to the sales team, the marketing team, or the operations team. They work in a dual capacity:
They understand central IT’s security, data, and compliance guardrails.
They write code in lockstep with the operational team’s daily processes.
The sales team gets the custom tools they need, and the company keeps its data secure. It moves engineering capacity to the front lines without sacrificing control. This is not central IT protecting its turf. It is the difference between a tool that outlives the person who built it and one that becomes an orphan the day they leave. The FDE handles the heavy lifting of connecting tools, while the business owner provides the process expertise. As PwC notes, while AI allows anyone to test ideas, businesses must rely on formal tech teams to industrialize this innovation.
What to say at your next management meeting:
Kill the citizen developer training budgets. Stop paying for generic prompt-engineering courses that promise to turn sales reps into developers. It wastes both money and productivity.
Stand up a Forward Deployed Engineering (FDE) unit. Hire or reallocate professional software engineers whose sole job is to be embedded directly within operational business units. They can build real, scaleable tools that add value for the business units.
Establish strict boundaries. Central IT must maintain control over the main pipelines and access rules. Embedded builders can work in safe, pre-approved zones.
Implement process-capture interviews. Have FDEs sit with department heads to document workflows before writing a single line of code, so you solve real business friction.
Additions to your vocabulary:
Forward Deployed Engineer (FDE): A professional software engineer embedded directly inside an operational business unit (like sales or marketing) to build local tools and integrations. They bridge the gap between technical standards and operational needs.
Solution Sprawl: The rapid, uncoordinated proliferation of custom tools and apps built by individual departments using low-code or AI platforms, leading to overlapping workflows and massive technical debt.
Citizen Developer: A non-technical employee who builds application or database integrations using low-code, no-code, or generative AI tools. While well-intentioned, they often lack training in security and scalability.
Security Zone: A pre-approved, isolated technical environment set up by central IT where builders can safely connect tools and write local scripts without risking the rest of the company’s data.
Want to know how I think you should build this out? Subscribe to the newsletter or visit the website to get it.
Key Takeaways for Busy Leaders
Save/Revenue: Every hour a rep spends building a tool is an hour not selling, so moving that build work to embedded engineers keeps quota-carriers on quota and ships tools that outlive their creators.
Pitfall: Centrally mandated citizen-developer programs fracture your single source of truth and leave central IT holding a mountain of fragile, undocumented code.
Deeper Dive: The rest of this piece covers how to stand up a Forward Deployed Engineering unit and the guardrails that keep it safe. Read on for the four moves.