As a self taught developer, LLMs can help you learn, it can help you explore ideas, and it can even build up a syllabus for you. It will also encourage you at every step to let it make decisions for you, paper over anything you don't explicitly call out, and be able to actually build mental models for you - your brain needs to do that work. You will have to find a learning style that works for you and is effective.
> 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.
My advice is to learn the fundamentals of software engineering. Take some good books or resources, learn what makes a practice good or bad and implement it via projects.
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.
I personally think context and prompt engineering are not useful things to learn. If you’re having trouble improving the reliability and maintainability of your systems, the solution is to learn how to design better systems. And that’s great news for you, because there’s a ton of resources out there to learn about systems design! That’s normal engineering, and it doesn’t change as quickly as AI engineering… which, full disclosure as someone who uses a lot of token every day, is overhyped anyway.
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.
The AI improves and that is some other entity's job.
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.
As a self taught developer, LLMs can help you learn, it can help you explore ideas, and it can even build up a syllabus for you. It will also encourage you at every step to let it make decisions for you, paper over anything you don't explicitly call out, and be able to actually build mental models for you - your brain needs to do that work. You will have to find a learning style that works for you and is effective.
> 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.
My advice is to learn the fundamentals of software engineering. Take some good books or resources, learn what makes a practice good or bad and implement it via projects.
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.
I personally think context and prompt engineering are not useful things to learn. If you’re having trouble improving the reliability and maintainability of your systems, the solution is to learn how to design better systems. And that’s great news for you, because there’s a ton of resources out there to learn about systems design! That’s normal engineering, and it doesn’t change as quickly as AI engineering… which, full disclosure as someone who uses a lot of token every day, is overhyped anyway.
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.
The AI improves and that is some other entity's job.
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.
Find a bootcamp, the fundamentals don;t change or get stale.