Post 7:
For my #QConLondon workshop next week, I’m using RAG to tune ChatGPT with QCon-specific content—so it can answer questions in context and boost learning for attendees.

qconlondon.com/training/apr...
7/7

Once you’ve democratized LLM access (like GPT-4, Claude, or OSS models), real advantage comes from tuning them to your domain. That’s where RAG and SLMs shine.
6/7

⚙️ SLMs (Small Language Models):
Smaller models fine-tuned on specific domains. They're fast, cheap, and easier to run—especially when your data doesn’t change much.
5/7

🧠 RAG (Retrieval-Augmented Generation):
Store your own data, search it at runtime, and pass it to the LLM for context-aware answers. Great when data changes often or needs to stay fresh.
4/7

That’s where RAG and SLMs come in. Both help bring domain-specific knowledge into the model—but in different ways.
3/7

Big takeaway for me relates to RAG and LLMs.

LLMs (like GPT-4) are trained on massive datasets and can talk fluently about things Napoleon and Python—but they don’t know anything about your specific domain unless it’s publicly available.
2/7

Ben Wilkes’ post truly resonates with my thinking. At #InfoQDevSummit, I'll be speaking about Chat Oriented Programming (ChOP) and agentic engineering—sharing how I used them to build a RAG for the InfoQ Certified Architect in Emerging Technologies certification at #QConLondon. #QConLondon

"...how do we prevent these concerns and use agentic engineering to deliver good-quality commercial software? In a word: discipline. We apply the same discipline—and very similar practices—that we applied to manual engineering as we do to agentic engineering."

Love this! I couldn't agree more.

Takeaways from me:
- Continually revisit your understanding of DDD (understanding what is truly an aggregate and why it matters)
- Make sure you don't split your transactions across service boundaries
- ...and, of course, make sure you can ship with autonomy. Afterall, that's the point (6/6)

Upper Bound: A Microservice shall be no larger than that which allows a two-pizza team to release a single complete, appropriately sized user story to production within a single day. (5/6)

Lower bound: A Microservice should consist of no less than an Aggregate (or at least an independent Entity) and the associated Services that operate on the entities of that Aggregate. (4/6)

Sarah references Kyle Brown and Shahir Daya's post "What’s the right size for a Microservice?" There are some great upper and lower bounds for a service size I really like. (3/6) kylegenebrown.medium.com/whats-the-ri...

I've struggled recently with a large team where we over-optimized a microservice architecture (dozens of services when a handful were really needed) so this phrase resonated with me. (2/6)

Key Takeaways #5
"We look for executives who can both scale up and scale down. Scale up: you can speak credibly to the board, at the right level of abstraction vs detail [...] Scale down: you know what “good” looks like for work all over your organization, you can get down in the weeds... "

Key Takeaways #4
"You want to hire people for their unique strengths, not their lack of weaknesses."

Key Takeaways #3
Start small. You should ALWAYS have as few employees as possible. Always. Hiring more people should never be the first lever you reach for, it’s what you do after exhausting your other options.

Key Takeaways #2
"Hypergrowth encourages a raft of bad habits, and attacking every problem by hiring more people is one of them." – @mipsytipsy.bsky.social

Key Takeaways #1
There has never been, nor will there ever be, a universal approach to leadership. What works for one person or organization might not work for another. What works depends on your culture, your challenges, and the tradeoffs you’re willing to make.