If you use AI coding agents every day, you've probably hit the same three walls I did:

1. Running out of tokens mid-task: You hit your rate limit on Claude right in the middle of a feature, want to switch to Codex, Gemini, or Pi (running Kimi K3, DeepSeek, or local Ollama models) to finish the job, and realize your whole setup or context is locked inside one tool's conventions.
2. Prompt bloat: Your AGENTS.md / CLAUDE.md file slowly turns into a massive wall of text where old decisions, half-baked ideas, and current tasks all pile up together.
3. Agents cheating on autonomous runs: Whenever you let an agent run unattended on a larger task, the moment a test gets hard, the agent "fixes" it by editing the test—or watering down its own instructions.

Over time, I built three separate repo templates to deal with this: one for day-to-day coding, one for early design exploration, and one for autonomous multi-agent loops. Today I merged all three into a single, open-source starter kit: AgentWork (MIT).

Zero vendor lock-in: switch agents and models mid-flight

Because all project memory, architectural decisions, active tasks, and session handoffs live in plain Markdown inside .ai/ (with entry points wired up for AGENTS.md, CLAUDE.md, Cursor, Copilot, and Windsurf), your context belongs to the repo, not the agent.

I like running the whole pipeline inside a Claude session—that way it can capture errors, fix them, and continue building autonomously. And if I run out of tokens mid-run, I can immediately run the remaining stages either manually or automatically with another agent. It also lets me mix providers by strength: for example, using one provider (like Claude) for the architecture, another (like Codex or Gemini) for cold validation, and Pi (with Kimi K3 or DeepSeek) for fast implementation passes.

In autonomous mode, the launcher (launch.sh + agents.yaml) natively supports switching or auto-escalating across:

• Claude Code (Anthropic direct, or routed via OpenRouter / local Ollama)
• Codex (codex) and Gemini (gemini)
• Pi (Fireworks Kimi K3, DeepSeek, or local Ollama models)

You can even set routing profiles (openrouter-first, balanced, sensitive, or local-only for air-gapped runs) so cheaper/faster models handle mechanical tasks and heavier models step in when a retry is needed.

One setup script, two ways to work

git clone https://github.com/apelov/agentwork.git
    ./agentwork/setup.sh /path/to/your-project

• Interactive & Exploration mode (ai/ → .ai/): Context is split into small files (PROJECT.md, DECISIONS.md, TASKS.md) loaded only when needed. When you aren't sure what to build yet, there's a design-exploration workflow that makes the agent pitch 2–3 competing options with honest trade-offs before touching code. (Bonus: there's a visible ai symlink to .ai so you can browse everything directly in macOS Finder without toggling hidden files.)
• Autonomous Pipeline mode (agentwork/): When you want to hand off a bigger build (GOALS.md), an orchestrator breaks the work into a dependency graph of Work Packages (WP01, WP02, ...) and runs workers in isolated Git worktrees.

Making sure autonomous agents can't grade their own homework

The autonomous pipeline enforces strict boundaries using plain Git and SHA-256 hashes (zero external dependencies, just Python stdlib + bash):

• Locked tests: Tests are written and committed before the worker starts. If the worker touches a locked test file, the merge is rejected.
• Sealed contracts: Every task spec and verification script is hashed (SEAL.json) before execution starts. If an agent tries to edit its own spec to pass the gate, the pipeline catches the tamper and refuses to merge.
• Goldfish context: Workers don't get your whole project history—they get a tiny, freshly generated GOLD_CONTEXT.md (~1.5k tokens) with just their task, their allowed file globs, and the test command they need to pass.

Before publishing, I put the multi-agent workflow to the test by having both Codex and Claude independently audit the codebase for bugs, edge cases, and overengineering—which caught some great corner cases around git diffs and process cleanup.

Feedback welcome!

This started from my own daily workflows, and there are certainly plenty of things that can still be improved, simplified, or battle-tested across different stacks. If you try it out, spot rough edges, or have ideas on how to make it better, any feedback, issues, or PRs are very welcome!

https://github.com/apelov/agentwork

I made an interesting discovery a couple of weeks ago - some models still in stealth mode were being offered for "free".
So, I pulled out some projects that had been on my "todo" list for some time, and bravely spent 5B tokens in a week (1.9B on the busiest day) on open-source projects.

* Together with researchers Marco Tiloca and Rikard Höglund, we finalized a long-standing C-implementation of the security-oriented OSCORE Multicast Notifications. ( https://datatracker.ietf.org/doc/draft-ietf-core-observe-multicast-notifications/ )
* Implemented a testbed to evaluate the draft ICMPv6-SEC (a new way of using ICMP to enable dynamic timer adaptation of the QUIC stack) and evaluated its performance over interplanetary links (e.g. Earth-Mars). ( https://datatracker.ietf.org/doc/draft-pelov-icmpv6-sec/ )
* Implemented an industrial-grade CORECONF implementation for our lab.SCHC embedded stack ( https://lab-schc.fr/ ).

But Why?
My reasons were clear - I did have projects I deem important for the community, which are being shared as open-source code. This way, people that are using it will not have to spend their tokens to solve the exact same problems. In addition, the work did require a non-trivial amount of validation and "steering" of the coding agents, which would certainly have taken a non-expert significantly more time and effort.

This is seen also with the developments in physics, mathematics, and all fields of science - thanks to AI, lost of the questions we can ask can be answered in a matter of days. Yet, the questions we can ask is infinite - so the focus now moves from the "how", to the "why" - which has always been the most important question anyway!

This is one of the key points I teach my PhD students - if I set up this experiment, if I try to answer this question - what would I do with the answer? What if things don't turn out to be the way I expect? Success, as well as failure, needs to teach us something.

We still need to learn "how" things are done. And that can be extremely challenging - and gratifying. There are many people who love playing chess and that continue competing - even though the vast majority cannot even beat the chess engine on their own smartphones!

But the real question has always been the "Why". Why do we do this?
And AI cannot help us with this one - it will make it even more important.

As Large Language Models (LLMs) like GPT-4 integrate into our daily workflows, we face a paradox: while they promise enhanced productivity, they may inadvertently erode human expertise.

The way TikTok (and similar platforms) has taken over the world is now known to seriously harm our brains, particularly in terms of concentration span (among other effects). Yet, TikTok is a pastime activity, not a productivity tool. If you need to work, you must get off TikTok and do something completely different (unless, of course, your work is TikTok-related).

Are LLMs going to become the TikTok of our work? Will the instant gratification from approving an LLM suggestion set the rhythm of our workday?

The temporary productivity boost from LLMs that we're witnessing today could be negated by a decline in our cognitive capacity. We might all become dependent on a new "walking stick" that we didn't need initially, but which would have altered our way of "walking." We may become unable to "run" again - yet we'll have to keep upgrading our "stick" just to continue limping through our daily tasks.

The Path of Least Resistance and Expertise Decay

LLMs offer an unprecedented cognitive shortcut, providing polished outputs with minimal effort. While efficient, this path of least resistance poses several risks:

1. Erosion of Learning Opportunities: Today's experts are yesterday's beginners with experience that was developed through a "productive struggle". As LLMs increase the productivity of today's experts, there is fewer entry-level work left for beginners. When the current generation of experts retires, how will this gap be filled?
   
2. The Dunning-Kruger Effect: Users might develop an inflated sense of expertise by accessing AI-generated content without developing true understanding. Yes, in lots of cases the generated content will be "good enough", but this is superficial. An expert writing a sentence may have 50 reasons to frame it the way they do, and when challenged, they can defend their choice. A beginner faced with a blank page will have to gradually build their own understanding of the topic before writing something, which may be less than perfect, but will leave permanent impact on the author.
   
3. Loss of Original Thinking: Our brains may gradually lose the "muscle memory" required for original content creation and complex problem-solving.
   
4. Stagnation of Innovation: As experts lose the need to challenge themselves, organizational efficiency and innovation may decline over time.
5. Content Saturation: The ease of generating expert-level content with LLMs could lead to an overwhelming abundance of information, decreasing the overall value and impact of expertise.
   

The Chess Master Analogy

Imagine if chess playing were a core human activity and chess engines were ubiquitous. Non-experts would never spend countless hours working on their skills, instead "complying" with whatever the computer suggests. The chess level of the general population would plateau at a beginner level, with true mastery becoming increasingly rare.

However, the analogy stops here because chess has clear rules and a clear goal. We can objectively know when a chess engine is giving good results. The scope of application for LLMs is much larger, and we can never be entirely sure if the output is not a hallucination. This over-reliance on AI tools could lead to a decline in human expertise across various fields, with no way to compensate for this decline.

Two constructive way to work with LLMs

1. AI as a Sparring Partner

Rather than viewing AI solely as a content generator or avoiding it entirely, we can leverage LLMs as intellectual sparring partners. This approach allows us to maintain control over our work while benefiting from AI's capabilities. For example:

1. Writing Assistance: Instead of generating entire emails or reports, use AI to review your writing for tone, clarity, and effectiveness.
2. Ideation Support: Bounce ideas off an AI system to get alternative perspectives or identify potential blind spots in your thinking.
3. Learning Aid: Engage with AI to explain complex concepts, asking follow-up questions to deepen your understanding.
4. Problem-Solving Companion: Walk through your problem-solving process with an AI, using it to challenge your assumptions or suggest alternative approaches.

This "sparring partner" model allows us to leverage AI's strengths while actively engaging our own cognitive abilities, potentially offering a more sustainable balance between efficiency and expertise development.

This is probably the most dependency-free option, but it has its downsides as well. The danger lies in losing autonomy. Soon, we may be letting the AI influence everything we write and do. The machine could become the ultimate judge of what is appropriate or not, what tone a letter should have, etc.

2. Second-best Option: Engaged Writing (Create-Write-LLM-Revise)

To harness the benefits of LLMs while mitigating risks, consider adopting a structured workflow:

1. Create: Begin with human ideation and planning
2. Write: Produce the first draft through human effort
3. LLM: Use AI tools for enhancement and refinement
4. Revise: Review, and possibly go back to step 1

This approach maintains active cognitive engagement while leveraging AI capabilities, helping to preserve and develop human expertise.

I wrote this post using this approach, but I can say I feel the dependency creeping in. Today I am capable of writing it on my own, but in 10 years' time, who knows?

What should we be doing?

• I don't believe regulation is the right approach today. We still don't know enough to implement any meaningful regulation in this area.
• Private enterprises are busy finding the right business models and use-cases for GenAI, or ways to maximize LLM use.
• Universities are on the front lines here, and I believe they have a critical role to play. The first step is to correctly frame the issue, add specific courses to the curriculum, and fully integrate GenAI into all existing courses. The worst approach would be to ignore or try to forbid the use of LLMs.

We cannot wait 3, 5, or 10 years for someone else to tell us that getting hooked on GenAI is bad.

Today, I believe it's a matter of personal discipline and individual introspection to find the right approach to integrating GenAI into our lives.

Artificial General Intelligence (AGI) is "years, if not decades away" according to Yann LeCun [source], requiring "new scientific breakthroughs that we don’t know of yet". Taken from one of the leading researchers in AI, I think this should be enough of a reason to believe AGI is not around the corner.

Another evidence in that direction, is Sam Altman's latest Manifesto - The Intelligence Age - where he phrases it as AGI will be here after "possibly few thousand days, or longer".

Sam Altman, among all people, and OpenAI in general, have a very strong incentive to bring AGI as soon as possible on the stage. In fact, it seems achieving AGI is the main strategy pursued by OpenAI's founders [source]. Even though, OpenAI doesn't seem to have a roadmap to follow [source], its entire  charter revolves around AGI. This seems like a page taken from Elon Musk's SpaceX, whose mission statement is about "making humanity multiplanetary". Only in OpenAI's case, there are many companies that are head-to-head with it and didn't require the AGI narrative to develop.

Altman is pivoting OpenAI from research lab to a "classical scale-up", as the company has losses of US$5bln this year (for US$3.7bln of revenue). The pivot from non-profit to profit structure will be clear only after the dust settles. For the moment, Microsoft detains 49% of the for-profit arm of OpenAI [source], Microsoft "have all the IP rights and all the capability" to continue operating its CoPilot "even if OpenAI dissapears". There is  this "fun" clause, which takes away all this IP from Microsoft ONCE OpenAI hits the AGI status. Which is not anytime soon. If anything, it would incentivize Microsoft to start hindering OpenAI the moment they suspect AGI is close to becoming a reality.

OpenAI is raising $6.5bln, with $1bln coming from Microsoft, $0.1bln from NVidia, $0bln from Apple (who withdrew), and $1.2bln from Thrive Capital [source]. Getting Thrive Capital's investment required a sweetener - the right to invest $1bln more at the same conditions if certain revenue goals are met.

It is surprising for the hottest company in the world, leading on the hottest topic in the world to have to sweeten its investment deals... every time.

Alexander