Javascript is one of my favourite languages out there. Im not sure if it just the familiarity with the language (have been using it since age 10) or the fast pace of change in the language space or the fact its being used on space craft - I think its a useful skill to have for anyone working in the software industry. Check out my rant on what makes JS so awesome according to me!
A builder without a technical background asked how to make software factories actually work. My answer is simpler than a better harness: build your understanding as you go. Every instruction is a chance to learn — ask the agent what it did, why, what the alternatives were. Good skills will carry a prototype a long way, but systems that last need you to understand how they're designed.
Question: I want to move toward software factories because people talk about them a lot, but I can't seem to use them properly — is it worth it, and how do I build a workflow that makes sense?
In this episode:
The question: why software factories don't work for a non-technical builder yetStep in with curiosity and a learning mindsetEvery instruction is a chance to learn: what did you do, why, what are the alternatives, pros and cons?Depth comes with time: data models, REST APIs, data storage, encryption, authenticationSkills and a good harness carry a prototype a long way — look at what Matt Pocock and Addy Osmani shareSystems that last need an understanding of system design, and sometimes the codeRelated episodes:
The Shifting Role of the Developer: From Writing Code to Writing SpecsFrom Coder to Architect: The Power of the Producer MindsetThe AI Autonomy Paradox: Why Software Engineers Must Unlearn "Control"Agentic Transformation Concept: Progressive DisclosureHave a question? Reach out on LinkedIn or Twitter.
A question from a young engineer: should you build depth or breadth in a market nobody can predict? I start with a different question — what kind of work do you actually enjoy? — then walk through where depth still matters (the AI frontier, trillion-dollar systems like Stripe, formal verification) and why breadth roles are becoming outcome-focused. My answer: try both, practise relentlessly, and set outcome-based targets for yourself.
Question: Should new software engineers focus on fundamentals or other things — depth or breadth — to succeed in an unpredictable market?
In this episode:
Start with what kind of work you enjoy — not everyone fits every pathWhy most people will be a better fit for breadth rolesWhere depth lives: model training, security, compute optimisation, and the ML frontierComplex systems at Stripe's scale need domain + technical depth to stay verifiedFormal verification: a new field that will demand depthBreadth = learning new domains fast; roles judged on pure outcomesSales, marketing, product, design — learn them on the go, deploy, get feedbackThe open question: how do juniors build depth when AI does the work?Practice, critical and Socratic thinking, and outcome-based targets apply to both pathsRelated episodes:
Are you a T-Shaped Developer?Whats makes a good software engineer?Stop Reviewing Code, Start Reviewing Tests: TDD in the Age of AIThe Shifting Role of the Developer: From Writing Code to Writing SpecsHave a question? Reach out on LinkedIn or Twitter.
"Forward-deployed engineer" is the title everyone wants. I share what it actually looked like for me: two weeks sitting in a field office that runs 200 schools, taking phone-call tasks about broken solar panels and missing teachers — and building tools in the afternoons until the coordinator asked to use them. Recorded live at a community session on agentic engineering (Urdu/English).
Question: Is forward-deployed engineering a real role — and what does it actually look like?
In this episode:
FDE is a company engineering role, not a freelance gig — and titles get abusedThe field office story: arrive with a blank slate, do whatever work they hand youBuilding on Replit from 2–6pm, using the tool yourself the next day, gaining your first userTwo intense weeks that ended in a contractRelated episodes:
Agentic Transformation: My StoryThe Shifting Role of the Developer: From Writing Code to Writing SpecsHave a question? Reach out on LinkedIn or Twitter.
Every generation of engineers has been told their craft is ending — assembly to C, C to Java, Java to Python. Using the story of photography, I argue AI won't end software engineering; it will turn far more people into builders and change what the job looks like. Recorded live at a community session on agentic engineering (Urdu/English).
Question: Do you think this is the last era of software engineering?
In this episode:
Assembly → C → C++/Java → Python: each shift was called the end of real programmingThe photographer analogy: cameras in every pocket, yet more photographers employed than everBuilders go from ~5% of the world to maybe 40% — imagine how much software that createsThe job changes; it doesn't disappearRelated episodes:
LLMs: Are AI Software Engineers ready to take over?The AI Code Revolution: What Developers Need to KnowAgentic Transformation: My StoryThe Shifting Role of the Developer: From Writing Code to Writing SpecsHave a question? Reach out on LinkedIn or Twitter.
Have you ever asked an AI to build something, only to realize it built the exact wrong thing? AI is incredible at generating code, but it lacks human judgment.
In this episode, I share the story of building an internal AI coaching bot called "Jugnu." My first attempt failed completely because I relied on the AI's judgment instead of doing the research myself. I quickly learned that the most successful AI developers spend 90% of their time researching, planning, and writing specs before they ever type a prompt.
Join me as we explore how the role of the software engineer is merging with the product manager, the death of "un-used software," and the exact frameworks and tools (like NotebookLM and Superpowers) you can use to master AI-assisted development.
This podcast, its content and its artwork are not owned by, affiliated with, or endorsed by Castquire.
