Got into AI early and now use ChatGPT and Claude constantly. With their help I've built a handful of web apps, some Python scripts and desktop tools, and an Android app on Supabase with real multiple users.
So I can build things. But I'm very aware there are big holes underneath it. I can usually get something working without really knowing why it works, whether it's actually well built, or what's going to break down the road once it gets more complex.
Feels like it's time to go back to fundamentals. Michael Jordan still worked on his footwork, that kind of thing.
What I'm hoping to get to eventually:
* build small useful apps, windows/mac/android/ios/web
* automate chunks of my own and my team's work
* maybe build a simple SaaS at some point
* generally not get left behind, open to this reshaping my career or spinning into a side thing
Was hoping for something structured, starting from prompt/context engineering and working into real programming fundamentals, APIs, databases, architecture, security, testing, deployment. Problem is anything I find is stale within months given how fast this moves.
Not looking for free necessarily, and definitely not looking for "learn to code in a weekend." Willing to put in real time.
For people who've gone down this road already: what's actually worth learning properly, what's fine to just learn enough to supervise, and what can honestly just stay AI's job?
P.S.: Yes I polished/refined this post using AI, but I first wrote it all myself (the original was twice as long).
AI can help tremendously but there’s so much you as a human understand about product direction and real-world use that the AI simply can’t. Everywhere you look, companies are popping up that are desperate to ingest data from every possible source in order to fix this context and intuition gap. But it’s just not possible. As long as you’re the one who ultimately decides what features you’ll implement, the model will be bad at guessing what to build for in the future. And anyway, you can spend all your energy learning how to squeeze the last 10% of work out of your model and harness and workflow but at the end of the day that’s time you’re not learning about designing resilient systems and actually doing the hard work of implementing them.
Bias: I’m a software engineer, and not super ai-pilled, so. There’s that.
Some ideas on what you should learn based on what you said:
Data modeling or database design: this is probably where AI-generated apps rot fastest as they grow. Learn normalization, indexing, and why schema choices matter.
Security basics: auth, input sanitization, secrets management, common vuln classes (OWASP top 10 is a fine starting ground).
Testing philosophy: not necessarily syntax, but why you test, what to test, and how tests let you (and the AI) refactor safely. This is probably the single most important thing for someone building with AI, since its a safety net for code you didnt write line-by-line.
System design and architecture basics: how to break something into services/modules, when not to, tradeoffs of monoliths vs. microservices at small scale, stuff like that.
I would really recommend you to learn syntax, however the bare minimum is to be able to read the code and actually understand it. For example, knowing when a function is doing too much.
Should you have expertise in your domain with strong fundamentals and capacity to envision a world's best prototype to make, as measured, knowing conceptually how the model reduces your inputs to the desired output is enough.
Experts do get frustrated when the AI quits short on their prompt.
SOTA example has senior engineer one shot flashcard vocab building app for language learning.
> what's fine to just learn enough to supervise, and what can honestly just stay AI's job
It depends what "fine" means. If your goal is to build more things quickly, LLMs can help. If you want something that is more complex than few-weekend project that is doing something bespoke, or things that others will work on, or that is in a critical area where defects kill the value or reputation, the less you will be able to lean on AI design. Simply put - if you don't develop a skill for determining quality, your projects will balloon in complexity until they grind to a halt, as I'm sure as you've seen as a director.
This opinion is not shared widely and certainly runs counter to LLM enthusiasts, but for your situation I think it might be more true than say an experienced developer who's seen things go wrong.
> Problem is anything I find is stale within months given how fast this moves.
My opinion is that this is an illusion from AI marketing. Prompt/context engineering is slippery because whats in and whats out day to day moves fast, but the actual practice of software is old. There are still quite relevant talks and books and resources from the 90s (nearly 30 years ago!) available. If you center LLMs and AI as the cornerstone of your practice, as almost all AI marketing would have you do, you will find it difficult to do anything, and you will forever be a passenger to LLMs - and as someone who uses them daily, you should trust them about as much as you trust a self driving car to navigate a dirt road.
I'd recommend a few short real actual books: The Pragmatic Programmer and Code Simplicity (Oreilly). They can help introduce you to the world of tradeoffs that is the core of building software.