I’ve been reading and watching a lot of videos about agentic engineering. Two people have caught my attention of late: Matt Pocock and Peter Steinberger. Matt Pocock is a developer who teaches TypeScript courses and makes YouTube videos. Peter Steinberger is the creator of OpenClaw, an AI agent framework that connects AI agents to users via instant messaging platforms. Both of them use AI almost exclusively for their work, but they work with AI differently.

Matt Pocock describes the skills and the workflow he uses in a fifteen-minute video. The gist of his workflow is this:

• Get your idea out on paper. Have the AI quiz you or work with your team to get on the same page.
• Make a product requirements document that describes the problem, the solution, what is in scope, and a definition of done.
• Split the PRD into separate issues that live on a kanban. This can be in your online issue tracker or they can live as text files in your repository.
• Let an AI agent decide what task to tackle, and have it commit to git when finished, basically a Ralph Wiggum loop.

He’s built several agent skills to help manage this workflow, which he publishes on GitHub. He calls /grill-with-docs, which asks you questions, much like an analyst would, about your idea. During the interview, another agent skill, /domain-modeling, records big decisions about your application’s architecture via architectural decision records (ADR). It also records project-specific language in a glossary file, CONTEXT.md.

This workflow works well, although it can burn a lot of tokens. That might just be the cost of getting good results with an LLM. Pocock theorizes that LLMs have a “smart zone” and a “dumb zone.” The “dumb zone” happens when the context fills up with more than about 100,000 tokens. After that, the vector relationships between each token in the context become too weak to give the AI a strong signal about the next output, and performances degrades. I don’t know if that’s true, but his method allows the LLM to continue work while starting with a fresh context for each issue.

Peter Steinberger disagrees. Now at OpenAI, the OpenClaw developer feels that AI agents are now much better at handling large contexts. But one thing they both agree on is that getting on the same page with your LLM is critical. His technique is much less structured: he says to just talk to it. That can work well, and it often delivers surprisingly good results in the early stages of a project. But what happens when your app’s code base starts to grow? That’s when your own skill as a software developer starts to gain importance. If you don’t understand good software architecture, your project quickly becomes unmaintainable.

Every new session with your LLM is like bringing on a new team member. It’s important to manage the context to smooth out this repeated onboarding process. Pocock argues that best practices for team management in software development are still relevant in the age of agentic engineering. This is what CONTEXT.md and CLAUDE.md (if you use Claude Code) attempt to do.

If you don’t have a coding background, a great way to get your foot in the door is to get familiar with the tools of the trade. The most foundational tool is version control software. Git is the most popular. What’s a branch? What is a commit? What does it mean to “stage” changes? What are rebases and merges? If you understand how version control software works, you improve your ability to communicate efficiently with an LLM coding agent.

Steinberger can get away with his informal “talk to it method” because he has many years of experience as a software developer. He knows what to focus on and he has a sense of what “good” code looks like. When he sees bad code being written in a chat, he knows how to course-correct. For the rest of us, we need a little more structure. But I agree with something he said on Lex Fridman’s podcast: that you should play. There can be great joy in creating software, and AI opens the door for more people to experience that joy. Just keep at it!

References and further reading