What is “loop engineering?”
Sometimes it takes a mini-book sized article to learn about a new agentic feature 😅 Nothing revolutionary about loop engineering, useful for low-risk work, one more thing to take humans “out of the loop”.
Sometimes it takes a mini-book sized article to learn about a new agentic feature 😅 Nothing revolutionary about loop engineering, useful for low-risk work, one more thing to take humans “out of the loop”.
At Deel, I created a PR to modify a shared database table used across all teams. When I announced my intention to merge it in the developers Slack channel, many people from senior tech leads to CTO jumped in to warm me against it. That felt embarrassing, but I learned more about the tradeoffs and alternatives than I could alone. Collect your battle scars at work. If you aren’t making embarrassing mistakes, you aren’t learning the lessons that will make you elite.
Interesting to learn how different companies solve LLM problems like parameter density vs. compute cost, context size vs. output quality, etc., and how they converge on reasoning.
The last one is the most hard hitting - The decision you make by not deciding. The conclusion is worth reiterating - Whichever doors you walk through, walk through them on purpose.
Moving interactivity from harness to model itself is clever, no doubt. What’s more interesting is how they solved constructing responses from partial inputs. And how responses from bigger background model is stitched back in interaction model.
Great deep dive on the deceptively simple concept of llm/agent memory. Biggest takeaway: it’s a game of accurate retrieval rather than storage.
It’s always fascinating to see agent setups people use to ship code to production. I tend to err on the side of using OOTB/native tooling unless something really comes in my way. If I were to pick a couple of improvements to my workflow based on the article, it’d be interactive HTML plans and agentic code reviews.
Captures the essence of Slow Productivity but with sharp and memorable anecdotes. I could personally relate to each and every example.
Routing is a great method of reducing token spend. Using a society of task-specific small language models is another. Both work to ensure the 80% light repeatable tasks don’t wastefully end up with fat models and only the genuine 20% do. Different techniques, different dynamics, different tradeoffs.
My favorite quote - “Tasks run out. If you are in a problem-solving role, you’ll know that you never run out of problems. The type of problems you solve today may fade away, but the supply of problems will not.”