I wrote my first production code in classic ASP, back when a "web application" meant VBScript tangled around ADO recordsets, and SQL Server was something you administered yourself because there was no one else to do it. Almost thirty years later, I'm writing this from a CRM platform I built with an AI coding assistant sitting next to me the whole way. A lot changed in between. A few things didn't, and those are the parts worth talking about.
ASP, ADO, and learning to think in tables
Classic ASP forced you to understand what was actually happening. There was no ORM quietly generating your queries, no framework hiding the round trip to the database. You opened a connection, you wrote the SQL yourself, you looped through a recordset by hand, and if a JOIN was wrong you found out immediately because the page just broke. It was tedious in exactly the way that teaches you something: you couldn't fake your way through it. You had to actually understand primary keys, foreign keys, and what a bad JOIN does to a result set before you shipped anything.
That's where the SQL fluency came from. Not a course, not a certification — years of writing queries by hand because there was no other way to get the page to render.
.NET, C#, and a different kind of discipline
The move to .NET and C# was a real shift, not just a new syntax. Strong typing, real object orientation, a compiler that caught mistakes before a user did — it changed how I thought about structuring an application, not just how I wrote the lines. But underneath the new architecture, the data layer hadn't gone anywhere. Stored procedures, indexes, execution plans — all of it was still there, just wrapped in better tooling. The people who treated the database as a black box some other layer would handle for them were the ones who got surprised in production. The database was never the part you got to skip.
Salesforce and the value of knowing what's underneath the declarative layer
Salesforce looked, on the surface, like it was designed to make the underlying data model disappear — clicks instead of code, declarative workflows instead of scripts. And for a lot of what it's used for, that's exactly the point, and it's a good one. But the engagements that actually mattered — migrating twenty-six enterprise applications into a single platform, redesigning a data model so it could scale — those were never won by knowing the point-and-click tools. They were won by understanding the relational structure sitting underneath the UI: what happens to child records when you restructure a parent object, how a bad data migration silently corrupts reporting six months after everyone's stopped paying attention to it. Apex and SOQL are SQL wearing a different outfit. If you already thought in relational terms, you were fluent in a week. If you didn't, the platform would happily let you build something that looked fine and quietly wasn't.
The unglamorous skill nobody markets anymore: VB, SQL, and real data migrations
Here's the part I think gets lost today. Somewhere along the way, knowing VB and raw SQL well enough to actually move and reshape data — not just query it, but stage it, clean it, dedupe it, reconcile it against a legacy system, and land it correctly on the other side — became a niche skill instead of a baseline one. It's not taught much anymore, and it's not something a course teaches you well; it's something you learn by doing a migration that goes wrong once, badly, and never forgetting why.
Every serious modernization project I've ever led has come down to the same unglamorous truth: the part everyone underestimates is always the data. Not the new architecture, not the new platform — the fifteen years of legacy records that have to survive the move intact. That's a scripting problem and a SQL problem before it's anything else, and it's the single most common place I've seen a modernization project quietly fail.
The tools change every few years. What a foreign key actually means, and what happens when you ignore it, has not changed once in thirty years.
Where AI actually fits into this
I use AI-assisted development every day now — this platform runs on it, and I'm not interested in pretending otherwise. It's a genuine step change in how fast a small team can build real software. But I'll say the thing a lot of vendors won't: using an AI coding assistant well and using one blindly are two very different experiences, and the gap between them is exactly the technical knowledge I spent thirty years building.
An AI assistant will write you a migration script, a data transformation, a bulk update — fast, and usually well. What it won't reliably do is know that your specific legacy system has a nullable foreign key that's been silently broken since 2014, or that the "safe" bulk UPDATE it just suggested is about to touch ten times more rows than you meant because of how a JOIN actually resolves against your real data. Catching that isn't a prompting skill. It's the same skill it always was — knowing what the query is actually going to do before you run it against production.
That's not an argument against AI. It's an argument for pairing it with real technical judgment instead of substituting one for the other.
What I'd actually tell someone starting out today
Learn SQL. Not "know enough to ask an AI to write it for you" — actually understand what a JOIN does, what an index is for, and what happens to your data when a migration goes sideways at two in the morning. Learn enough basic scripting that you can read what a tool generated for you and know whether it's right, not just whether it ran without an error. Those two things have outlasted every framework, every platform, and every hype cycle I've worked through since 1998, and I don't expect that to change because the tools got smarter.
And if that's not the path you want — if your strengths are somewhere else entirely — then the honest advice is the same one I'd give a client: work with someone who has that grounding before you let AI touch anything that holds real data. The risk was never really about AI. It's about moving fast on something you don't understand well enough to know when it's wrong.