Stop Peanut Buttering AI Onto Your Organization
Spreading AI thin across your existing workflow won’t work.
Teams are taking their existing processes—the same standup structures, PR review cycles, team compositions they’ve had since 2019 (or before)—and just adding AI on top. Like peanut butter spread thin across everything.
A little Copilot here. A ChatGPT tab there. Maybe an AI summarizer for meeting notes. Then they wonder why they’re not seeing the gains everyone keeps talking about.
The teams actually seeing gains aren’t just “doing AI”, they are changing the way they work as engineers and knowledge workers to adapt to how this tool is different from the ones that came before.
And I don’t say that in a grandiose “AI is the second coming” way, but just in a practical way: it takes a different approach to use a non-deterministic tool like AI well. Some tools like compilers or code quality tools or other deterministic software packages can have marginal benefit from the peanut butter method. But AI just isn’t the same kind of thing, and needs to be treated differently because of it.
The Thin Spreading Problem
When you peanut butter AI onto your current workflow, you get peanut butter results: a thin layer that doesn’t fundamentally change anything. You’re optimizing at the margins, and then acting surprised when you get marginal results.
This is like when companies “adopted Agile” by renaming status meetings to standups and project managers to scrum masters, but changed nothing else. The ceremony was there for sure. But I remember being asked in a meeting once what we planned to have done in the next 12-18 months…and when I mentioned that we weren’t using waterfall was told, “Oh no, use Agile, but just tell me what we can guarantee will be done in the next year to the customer.”
The Zapier Framework for AI Fluency
Wade Foster, CEO of Zapier, maps AI skills across four levels:
Unacceptable: Resistant to AI tools and skeptical of their value.
Capable: Using popular tools with under three months of hands-on experience.
Adoptive: Embedding AI in personal workflows. Tuning prompts, chaining models, automating tasks.
Transformative: Uses AI to rethink strategy and deliver user-facing value that wasn’t possible two years ago.
Most organizations peanut buttering AI are stuck between levels 2 and 3. They’ve adopted the tools but are trying to fit them into the same old stale paradigms. They aren’t really rethinking what it would look like to care about using AI in a strategic way that actually delivers more value.
The jump to level 4 requires asking harder questions: What work can we now do that we couldn’t before? What roles need to change? What processes no longer make sense? What meetings can we eliminate?
In a lot of ways this reminds me of the fast and hard transition to remote work during the pandemic. Some companies used it as an opportunity to rethink how they get business done and they benefit tremendously from that transformation. Others just stuck all of their middle managers in 12 hours of Zoom meetings a day.
I’ve Seen this Movie Before
Scott Breitenother, CEO at Kilo, put it bluntly in his Kilo Speed Manifesto:
The old software development paradigm:
Developer productivity = lines of code
Collaboration as the default (meetings, handoffs, “alignment” forever)
Velocity killers everywhere: waiting on PRs, waiting on other teams, constant context switching
The new paradigm:
Developers define the vision and manage AI agents to execute
Engineers own products end-to-end—collaboration becomes optional
No one waits on a PR review or another team to unblock them
This isn’t a theoretical manifesto, it’s how we’re actually shipping. At Kilo, we ship 1-2 major features a week, compared to a feature every 2-3 weeks at most “fast” software companies. The difference isn’t that we work harder or have better engineers. We stopped working like it’s 2023 and started working like it’s 2028.
One Engineer, Multiple Agents
Stop thinking about AI as a tool that makes your current team slightly faster. Start thinking about what a team looks like when one engineer can direct multiple AI agents.
The old model: Suresh, Evgeny, and Ramon (real Kilo engineers, by the way) collaborate on a feature. They divide the work, write code, review each other’s PRs, sync in standups.
The emerging model: Suresh owns the feature end-to-end, directing AI agents to handle implementation while he focuses on architecture, edge cases, and verification. Evgeny and Ramon are doing the same thing on their own features.
At Kilo, each engineer owns a feature end-to-end. No extended PRD committee phase. No waiting for signoff. Engineers use our Architect Agent to design, Orchestrator Agent to break up tasks, Code Agent to build, and Debug Agent to troubleshoot before sending PRs to our AI Code Reviewer.
The proof: Evgeny applied on a weekend, was hired Wednesday, and started Monday. His first code commit was on Monday, first demo Tuesday, with a working MVP by the end of the week. The feature— App Builder—went GA just two weeks later.
That’s not because Evgeny is superhuman. It’s because the system is designed for one engineer to own and ship end-to-end.
What This Means For Engineers
This is actually good news. The path to impact is getting shorter. You don’t need to wait for a team to be assembled and aligned. You can own more, ship more, and demonstrate more—if you develop the skills to work effectively with AI.
But “work effectively with AI” is doing a lot of lifting. It’s not just “use Copilot.” It’s:
Understanding how to break problems into AI-tractable pieces
Managing context across long coding sessions
Knowing when to trust the output and when to verify
Writing specs that AI can actually execute against
Reviewing AI-generated code effectively (which is different from reviewing human code)
These skills are learnable, but they’re different from what got most of us to where we are today.
What This Means For Leaders
The question isn’t “Should we use AI?” You probably already are. The question is: are you peanut buttering, or are you transforming?
Signs you’re peanut buttering:
AI adoption is tool-by-tool with no coherent strategy
Team structures and processes are unchanged from pre-AI
You’re measuring “AI adoption” by license count, not output
Engineers use AI on the side but it’s not part of how you plan work
You haven’t rethought what roles should exist
Signs you’re transforming:
You’re asking what work is now possible that wasn’t before
Team structures are evolving based on what’s actually effective
Individual engineers are owning larger scopes of work
You’re developing organizational capabilities around AI, not just buying tools
The way you measure productivity has changed
The transformation is harder. It requires rethinking things that feel like they work well enough. But “well enough” is a moving target.
New Boss, same as the Old Boss
Guillermo Rauch (Vercel CEO) recently noted that his 17 rules for successful agentic coding are really just the Unix philosophy:
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
The principles that made Unix powerful in 1969 are the same principles that make AI-assisted development effective today. Small, composable pieces. Clear interfaces. Simplicity over cleverness.
The human becomes the architect and reviewer. The AI becomes the implementer. Instead of three engineers collaborating through a series of PRs and code reviews, one engineer drives AI agents to produce the same output—but they need to think in modules, in clear interfaces, in composable pieces.
The Bottom Line
Scott closes the Kilo Speed Manifesto with something that stuck with me:
Today, we call it Kilo Speed because it’s something special. But, if we do our job right, a year from now, we’ll just call it software engineering.
That’s the thing about paradigm shifts. At first they seem like a special case. Then they become the default.
Don’t be peanut butter. Be Unix.
If you’re thinking about developing these skills, I’m building out Learn Agentic Engineering—free content on YouTube now, with a paid certification coming soon. And if you want to try agentic coding yourself, Kilo Code is open source with completely free options.