axi0m

We recently rewrote MerciYanis entire codebase (~250K LoC, at our humble scale) in a single day, with only two small regressions in QA.

Achieving this required a radically different approach to code: we stopped editing the code itself and focused on shaping the system that produces it, and more importantly, the guardrails that protect it. Git, tests, agent policies, all working together.

From my experience, smaller models like Haïku 4.5 have indeed shown very convincing results on specific, scoped tasks (themselves generated by a more capable model such as Opus 4.6). We use this kind of workflows in production to optimize speed, efficiency, and costs.

This blog post relates our path to agentic product features shipping, the technical and human challenges we faced.

The worst part in all that noise: ask your customers what they need ; they will tell you "AI features". No matter what it is, or even how it compares to more traditional approaches when it comes to solving their pains. These two letters got beyond obsession.

I'm observing pretty much the same pattern in my job. The sad truth is, people -especially non-technical- get too easily impressed by vibe-coded projects or contributions made in a few hours, because it's shiny and it gives the impression of a productivity boost. Don't you dare asking how that is supposed to scale, if it's secure or even extensible, or you'll be the one killing the mood in the room. Even though that's precisely the hard part of the job.

I have always been deeply grateful for all the amazing content that brilliant engineers have posted online for the past 20 years. I've learn so much from it, avoided so many mistakes and discovered such incredible technologies. As a humble contribution to the industry, I'm glad to launch our new engineering blog, on which we will post stories about what we built, how we did and the challenges we faced. Starting with a deep dive into our observability stack!

That one is especially disturbing: https://www.moltbook.com/post/81540bef-7e64-4d19-899b-d07151...

Gosh, this story resonates so much with me... I had the exact same experience few days ago, desperately trying to get a small agent prototype working for a quick demo. I spent an good hour dealing with that pile of nonsense. Online payments and accounts management have been mastered for 20 years now, why do we still have to endure such things? It just kills me. The same goes with Azure (and all MS online-related services), if not even worse.

I'd like one of these as my screen saver. Great work!

You're talking about a neophyte trying to accomplish an engineering job. So yes, in such case, LLMs dramatically change the game, at least for entry-level tasks. Nowadays, anyone can litteraly pretend to be good/average in any field.

The article relates about actual, experienced engineers trying to get even better. That's a completely different matter.

Great post. The author precisely described what I have been experiencing for the last months of digging deep into that field (with quite a lot of anxiety at first, hearing here and there what a miracle it was). As long as we don't solve context window limitations and self-improving/continuous learning problem, human engineers still have a long way ahead of them.

Source code available at https://github.com/sapientinc/HRM

>> what if we treated prompts as the actual source code?

And they probably will be. Looks like prompts have become the new higher-level coding language, the same way JavaScript is a human-friendly abstraction of an existing programming language (like C), which is already a more accessible way to write assembly itself, and the same goes for the underlying binary code... I guess we eventually reached the final step in the development chain, bridging the gap between hardware instructions and human language.

Wow, nice optimization.

I personally use that lib: https://github.com/openizr/gincko Still in beta, but quite stable though.