A practical look at Techwondoe’s AI Workflow Kit, and how teams can use AI to move faster while preserving engineering judgement, shared context and craft.
AI should help developers learn, not give us permission to stop learning.
AI can help us build software faster. The more important question is whether it can help us build software better—without weakening our understanding of the systems we are responsible for.
That question is behind the AI Workflow Kit, an experimental agentic development workflow we are piloting across our projects. The Kit brings together reusable skills, shared project context, coding standards and verification steps to give engineers a more consistent way to work with AI tools.
The aim is not to step away from the work. It is to use AI while staying close to the code, the domain and the decisions that matter. We should never stop trying to master a codebase
It is still early. Over the next few weeks, we will test the Kit in real project work, learn where it helps and be candid about where it gets in the way. We are not treating the first version as a finished system. The workflow itself should improve through use, feedback and shared ownership.
| Area | Current direction |
|---|---|
| Pilot window | Two to three weeks of use in real project work |
| Approach | IDE-agnostic, combining shared context, reusable skills, standards and verification |
| What we will observe | Adoption, preventable errors, consistency and developer understanding |
| How it will evolve | Collective feedback, followed by fortnightly or monthly improvements |
Most developers already have access to capable AI tools. They can ask for code, generate tests, explore an unfamiliar repository or sketch a solution in minutes.
But access alone does not produce a good engineering practice.
Without a shared workflow, every developer has to work out their own way of prompting, supplying context, checking output and deciding when to trust or challenge the result. The quality of the outcome can vary significantly, even within the same team and codebase. Useful knowledge also tends to remain inside individual conversations instead of becoming part of the project.
The AI Workflow Kit is our attempt to make that process more deliberate and repeatable. It is designed to work across different AI-enabled development environments rather than being tied to one IDE or assistant.
The tools may change. The engineering discipline should remain.
There is a real risk in making automation too convenient. If a tool can inspect the repository, propose a plan, write the code and run the tests, it becomes tempting to accept the result without developing a proper mental model of the change.
Over time, we may ship more code while knowing less about the systems we own.
That is not the future I want the Kit to encourage.
Learning by doing still matters. Engineers need to understand the domain, recognise the trade-offs, question assumptions and be able to explain why a change belongs in the codebase. AI can shorten the path to that understanding, but it should not remove us from it.
This is why feedback loops are built into the workflow. The assistant should ask clarifying questions when a ticket is vague, push back when information is missing and make its plan visible before implementation. The developer remains involved throughout—not simply as the person who approves the final diff, but as an active participant in the reasoning.
The loop matters more than any single AI response: context informs the work, the engineer remains accountable, and what we learn improves the next task.
Good AI output depends heavily on good context. A repository contains code, but code alone does not explain every business rule, naming convention, historical decision or piece of domain language.
The Kit introduces shared context files that capture this knowledge in a form both developers and AI assistants can use. That includes:
This serves two purposes.
First, it reduces repeated relearning. Instead of explaining the same concepts in separate conversations, we can promote useful knowledge into a shared project resource. That saves time and tokens, but more importantly, it makes the knowledge available to the whole team.
Second, it reduces unnecessary variation in generated code. When naming, environment use, testing expectations and structural conventions are explicit, the assistant has a clearer definition of what “good” looks like in that particular project.
I see this context as a living part of the codebase—not a document we create once and forget. It should evolve as engineers discover new rules, make decisions and learn where the original assumptions were incomplete.
The Kit separates frequent development commands from supporting skills that operate around them.
| Command skills | Supporting skills |
|---|---|
| Learn an unfamiliar codebase | Clarify or “grill” an ambiguous ticket |
| Sketch a solution | Inspect and refine coding standards |
| Implement a ticket | Challenge a proposed approach |
| Make a focused change | Update shared project context |
| Prepare a handoff | Maintain decisions and documentation |
For implementation work, the intended flow is straightforward:
Simple tickets should move through this process quickly. Vague or high-impact work should slow down and invite deeper questioning. That distinction matters. A workflow that treats every task as equally complex becomes cumbersome; one that treats every request as obvious becomes unsafe.
The current Kit can infer coding standards from an existing repository. That is useful as a starting point, particularly for mature projects where conventions are already visible in the code.
However, we should not blindly accept AI-generated standards any more than we should blindly accept AI-generated code. The inferred rules need human review. Over time, we want to establish strong defaults for common project types while still allowing for client needs and project-specific decisions.
Those standards can draw from the existing repository, maintained organisational defaults and client-specific requirements. AI can help uncover implicit patterns quickly, but people still need to separate intentional conventions from accidental inconsistency and decide when a local difference is justified.
There is also an opportunity to compare local practices with shared organisational standards. The goal would not be to force every codebase into an identical shape. It would be to make differences visible, understand why they exist and decide consciously whether to keep or address them.
Consistency is valuable when it reduces avoidable confusion. It should never replace judgement.
Token usage came up repeatedly in our discussion, and rightly so. The first-time setup and coding-standards analysis can consume a meaningful amount of context because the assistant needs to inspect the repository and build an initial understanding.
The profile below is intentionally qualitative. It shows our current expectation, not measured usage from the pilot. The bars indicate relative context load, not token counts.
| Activity | Relative context load | Reason |
|---|---|---|
| First-time project setup | █████ | Builds an initial model of the repository and its terminology |
| Coding-standards scan | ████░ | Examines patterns across a broad part of the codebase |
| Daily implementation | ██░░░ – ████░ | Varies with ticket ambiguity, scope and verification needs |
| Focused context update | ██░░░ | Promotes a small amount of new learning into shared files |
That upfront cost is easier to justify when it happens once and produces a reusable foundation. Daily tasks should then be more focused, drawing on the parts of the project context that are relevant to the work at hand.
We need to keep our context files concise. More context is not automatically better context; a smaller, well-maintained set of relevant information will often outperform a large collection of stale detail.
Efficiency is part of the pilot—not an issue to postpone until later.
One of the most promising next steps is to capture project knowledge earlier—before implementation begins.
Important information is often created during discovery: assumptions, dependencies, business rules, risks, terminology and the reasoning behind a proposed solution. If that knowledge does not travel with the project, engineers have to reconstruct it from tickets, meetings and conversations. AI assistants face the same gap.
I want the Kit to help carry that context from discovery into delivery. That could make onboarding faster and technical decisions better grounded in the problem we are actually solving. It broadens the idea of project context beyond recent code changes. A codebase is a technical representation of a business domain; our workflow should respect both sides of that relationship.
We are also exploring stronger support for test-driven development and clearer escalation into architectural decision records when a change introduces a lasting technical choice.
The pilot is not successful simply because people use the commands. Adoption matters, but it is only one signal.
We will look for evidence that the Kit helps us:
I also want the team to tell us when a skill is redundant, too expensive, too slow or simply unhelpful. Removing what does not work is part of improving the system.
That means narrowing expensive skills when they load more context than a task needs, simplifying steps that add friction without catching problems and strengthening review checkpoints if the workflow makes developers less engaged. When a project genuinely needs different standards, we should make that difference explicit rather than forcing false uniformity.
The AI Workflow Kit is not an attempt to automate engineering judgement. It is an attempt to create the conditions in which that judgement can be applied more consistently—with better context, clearer checks and less repeated effort.
We should learn alongside AI, not defer our responsibility to it.
If we can preserve that principle, AI can become more than a shortcut. It can become a useful partner in how we understand, build and continuously improve software together.
Key Takeaways
Key Takeaways
End of Article · 15 min
A thoughtful, AI-assisted redesign of Techwondoe.com
A behind-the-scenes look at how Techwondoe redesigned its website with AI-assisted workflows across research, design exploration, prototyping, engineering, and SEO.
Techwondoe Toastmasters: Personal & Professional Growth.
Discover how Techwondoe Toastmasters empowers employees with confidence, leadership, public speaking, and communication skills through engaging and collaborative sessions.
STA: How to make remote work more fun?
A reflection on continuous learning, personal growth, and the importance of constantly improving technical and professional skills.
