In this post, published on 23 April 2026, Tim Deschryver describes using agentic AI over a month to rewrite a project entirely from scratch — an ASP.NET API backend with an Angular frontend, orchestrated by Aspire, built as a sandbox for learning what AI can and cannot do. His claim is that no complex setup or endless prompt tricks are needed: in his experience a few practices — an AGENTS.md file, Agent Skills and specifications — can dramatically improve the speed, quality and consistency of agents.
He is explicit that he did not vibe code the project (see Vibe Coding), because he thinks the practice causes problems in the long term. Instead he uses a road-cycling metaphor: the AI is a (super-)domestique working for the team, and the developer remains the team leader who sets the strategy, owns the direction and quality of the project, and has to cross the finish line.
Key Points
- He set up the project structure himself before letting agents loose, using a vertical-slice architecture that, in his view, also helps the agent by separating use cases.
- The
AGENTS.mdfile is always in the agent’s context, so it should hold general guidelines, project structure and the commands the agent can use; he notes it can be generated by the agent, should be reviewed regularly, and can be kept current by asking the agent to update it after a new concept is introduced. He also added recurring mistakes to it, and a Mermaid database diagram to help the agent understand the data model. - He prefers the standard
AGENTS.mdname across tools, and — since Claude Code does not read that file in his account — links it with a symlink or an@AGENTS.mdreference instead of keeping separate copies per tool. - Skills differ from
AGENTS.mdin being loaded only when relevant, which keeps the context window manageable; they can also be invoked on demand as slash commands. He used official Angular and .NET skills, and a custom design-system skill that he found necessary to keep generated UI consistent — more so with the Codex models than with Claude. - He avoids most MCP servers because, in his experience, they bloat the agent’s context window and lower output quality, and prefers skills and CLI tools for the same tasks.
- For larger features he used spec-driven development with OpenSpec, which generated a proposal, a design and a task list from a few sentences of prompt; for smaller changes and bug fixes he prompted the agent directly. Without a spec on larger features, he found the agent often missed subtle details, costing extra iterations. He names GitHub Spec Kit as an alternative.
- He found Claude and Codex models equally useful apart from Claude being better at design tasks, and describes the tool around the model as the harness, which he believes is getting thinner; he prefers OpenCode because it lets him switch models and providers and avoid vendor lock-in.
- His workflow: generate a plan with OpenSpec, have the agent implement it, test functionally and review the critical code paths in depth — treating some generated code, such as custom UI components, like a third-party dependency whose public API is all he inspects — then commit and open a pull request through git and GitHub skills.
- He expects shorter delivery cycles to demand more frequent check-ins and reviews, and the Product Owner or Project Manager role to matter more, because the risk becomes an overflow of low-value features rather than a shortage of time.
Context
The author states that he is not an AI expert and that this is his own experience as the sole developer on the project, so the recommendations rest on one person’s rewrite rather than on a comparison. His closing advice is to start with the default agent and add these files only when the agent keeps making the same mistakes, to keep instruction files tool-agnostic and bridge tool differences with symlinks, and to re-evaluate the setup continuously; he sees the engineer’s role shifting towards providing guardrails for the agent while keeping ownership of the product.