There's no short supply of flashy demos showing autonomous agents building entire applications from a single prompt. As OpenClaw creator Peter Steinberger puts it:

“From the commits, it might appear like it’s a company. But it’s not. This is one dude [me] sitting at home having fun.”

This is all fine and good for hobby projects and scrappy startups. But for many engineering teams, integrating these tools into a real-world production environment (with high stakes and even higher levels of skepticism from leadership) feels out of reach.

This disconnect leaves many developers feeling like they are falling behind or that the promises of “agentic engineering” are unrealistic for complex, legacy systems. Falling behind is inevitable for companies that hold out on agentic engineering, but I’m here to tell you that it is definitely possible for individual devs to bring the principles of this way of working to their roles, even if they’re not at an AI-forward company.

Yes, there are challenges with implementing agentic engineering practices. But there are also emerging solutions, techniques, and best practices—they’re just not consistently documented. Let me give you some examples:

Challenge 1: Unlearning the Single-Threaded Mindset

Most developers are trained to work in a “single-threaded” way: you write code, you wait for a build, you fix a bug, and you move to the next task. But agentic engineering changes the map about what one person can ship and requires a mental shift toward parallelism, which is surprisingly difficult to maintain. Developers are allergic to context switching! Learning to manage a team of agents takes a different mindset.

Evgeny Shurakov, who recently joined Kilo, embraces “Architect Mode”. When working on a new feature, he spends the majority of his energy on the discovery document and the technical plan. Once the plan is solid, he doesn’t just sit and watch the AI work. He kicks off multiple specialized agents in parallel—one to handle UI, one for backend logic, and another for testing. While these agents execute the “boring middle” of the project, Evgeny is already planning the next feature. He’s essentially operating as a UI engineer, backend engineer, and test engineer simultaneously. Evgeny is one person shipping at a pace that used to require a whole squad, and that’s what Kilo Speed looks like in practice.

Challenge 2: The “Yes-Man” Problem and the Lack of Dissent

One of the hurdles in adopting agentic engineering is that Large Language Models (LLMs) are, by nature, the ultimate confirmation bias machines. If you provide a flawed architectural plan to an agent, it will often happily implement it without pointing out the logic flaws or long-term maintenance risks. This creates a dangerous feedback loop where a developer can move very fast in the wrong direction or discover gotchas too far down the road. Some engineering orgs would rather pilot AI projects in sandbox environments (if at all) than take on this risk.

John Fawcett, an engineer on our team, wanted to avoid this pitfall while building a complex AI adoption dashboard. He found that the key to avoiding the “Yes-Man” trap is to use AI for context, but humans for dissent. Before writing a single line of code, John uses agents to critique his initial requirements and identify holes. But for high-stakes architectural decisions, he seeks out human opinions specifically to provide the “no” that an LLM probably won’t give. The lesson here is that as we delegate implementation to agents, enabling individual engineers to operate like the managers of their own teams, there is still room for human collaboration and healthy dissent.

Challenge 3: The Bleeding-Edge Knowledge Gap

A common frustration is that agents often lack knowledge of the most recent technologies. While an agent might have an intuitive understanding of a mature framework, it has no context for an SDK released two weeks ago. With new models and supporting technologies releasing every week, this is more often the case than not. This “knowledge gap” often leads developers to abandon agents for cutting-edge work, believing the tools are only useful for boilerplate.

Florian Hines, a platform engineer at Kilo, manages knowledge gaps through a “dual learning” process. When he built a remote sandbox foundation using a brand new Cloudflare SDK, he pulled the SDK code from GitHub and fed it directly to the agent as context. He treats the agent as a partner in learning the new tool. By providing the agent with the “proof” of how a new API works, he can use agents even on the most experimental parts of the stack.

Codifying the Unwritten Rules

The solutions to these challenges are not platform features; they are mental models and cultural practices developed by individual engineers experimenting on the ground. Currently, this knowledge is siloed within a few forward-thinking teams.

It doesn’t have to be this way! The democratization of AI tools and the knowledge surrounding them is what will ultimately drive the industry forward. We need a pragmatic, hype-free map for managing this transition—a community-driven repository where real engineers can share what’s worked for them.

Agentic Engineering for Humans, an open-source handbook, is my attempt to start that conversation. The goal is to create a trusted resource that helps developers reclaim their time from tedious tasks and focus on the high-value problems that actually move the needle for their users.

I am looking for contributors to help make this a living document of what is actually happening in the field, covering the practicalities that demos often ignore:

Implementation is increasingly becoming a commodity (code is cheaper every day); the intent and the architecture are where the value lies.

You can find the resources and contribute to the project at path.kilo.ai.