DEV Community: Peng Qian

Most AI coding workflows start to drift once the context gets too long. I introduced a graph engine based on a state machine to the AIDLC workflow. This engine guides the workflow's execution, which solves the drift problem.

Peng Qian — Fri, 23 Oct 2026 03:48:08 +0000

Peng Qian

Oct 23

How I Fixed the AI Coding Workflow Drift with a Simple Script

#ai #programming #productivity #vibecoding

18 min read

How I Fixed the AI Coding Workflow Drift with a Simple Script

Peng Qian — Fri, 23 Oct 2026 03:47:12 +0000

Judgment to the model, precision to the tool, decisions to humans

What stops you from using AI coding at scale in your work?

Besides the fact that AI generated code quality is not stable, another big problem is that AI never follows the process you told it to follow.

You tell it to do requirements analysis first, and it just runs off and starts writing code. You make a five step plan, and by step three it forgets what the first two steps decided. Open a new session, and it cannot even remember where it left off yesterday.

Over the past few months, our team used a Python script to fix this bad habit of AI. This script acts as a navigator for the AI coding workflow. It uses a graph based on a state machine, and this graph decides where each step should go. Since then, the AI coding workflow has never drifted again.

In this article, I will show you how we did this.

This article was first published on my personal blog, Data Leads Future. You can find the source code for this article at the bottom of my original post, and I will also answer your questions there in detail.

What Problem I Ran Into

I have been formally pushing AI coding in my team for more than half a year now.

At first, we only made the kind of demo used to show off a product idea. It looked cool, but it could not really be used.

Later, we brought AIDLC into our AI development workflow. This is a workflow skill that came from Amazon, and it is a set of workflows made to standardize the AI development life cycle. It fully follows the enterprise level SDLC (software development life cycle) process, and it guides the LLM to generate code through detailed spec files.

After a few months of tuning, we were finally able to get AI to build applications that run stably in production.

I also shared our experience using AIDLC online, and it got a warm welcome from many people.

But as the work went on, we found that AIDLC could only help us build small projects or small features. When the project got bigger, problems started to show up.

When the context got too long, or when we switched sessions, AIDLC would start to lose track of the spec documents. This caused the whole workflow to stop strictly following the spec files generated ahead of time, and in the end there was always a bug or some gap in understanding.

We also switched back to OpenSpec and Superpowers to test it out, and the result was the same. Both had the problem of workflow drift.

Why This Problem Happens

The root cause is that these are all workflow frameworks based on SDD (spec-driven development).

Whether it is AIDLC's skills or OpenSpec's commands, they are both made up of dozens of Markdown files. These frameworks get loaded into the harness when the session starts, and this takes up 30k to 50k tokens.

At the same time, before coding even starts, an SDD based development workflow also generates a large number of spec files. These files also get loaded into the context, and they take up a lot of the context window.

Frontier models often have context windows of more than 1 million tokens. It looks like they can hold a lot, but the model does not pay the same amount of attention to every position in the context.

Once a key rule document falls into a low weight zone, the model ignores it, and the instructions start to drift. It is like a thick instruction manual. The further you flip through it, the less you remember about the details at the front.

This is especially true for models like deepseek-v4.1-flash, which have a very long context window and super cheap caching. To chase a high cache hit rate, people tend to stuff a lot of content into the context window. Then they find that once the session gets long, the coding quality of these models drops a lot, and their ability to follow instructions also goes down.

In an article I wrote last year, I explained why LlamaIndex at the time could not accurately carry out workflow tasks based on the handoff mechanism. The reason was that the context was too long, and this caused the process to drift.

Using a Graph Engine in AIDLC

Now that we know where the problem comes from, the next step is to look at how to fix it.

The answer is not in the AI itself, but in traditional agent frameworks. These frameworks figured out one thing a long time ago: who should drive the workflow should not be left entirely to the LLM's own judgment.

But if the goal is the same, having agents hand off tasks to each other, why did everyone end up choosing the graph engine path? To answer that, we need to look back at a bit of history in multi agent frameworks.

In early 2025, OpenAI released an agent framework called OpenAI Swarm. The core idea of this framework was to let the LLM call a function called handoff. This let the main agent hand off a planned task to a sub agent to carry out, which created a planner-executor architecture. Does this sound a lot like how modern AI coding tools (harnesses) use the task method to call up sub agents?

But this framework had a big limitation. When to hand off which task to which agent was written in the prompt given to the LLM. Because of this, the framework only worked well on the most advanced GPT models of that time. It did not work with other open source models. The root cause was that open source models back then were not yet good enough at following instructions.

This is why LangChain's LangGraph, which came out later (along with Crew.ai from around the same time), used a different approach. It used a scripted execution engine based on a state machine and a directed acyclic graph (DAG).

This approach is actually simple when you say it out loud. You use a Python script to first define a traditional workflow based on a graph. Each node in the graph is an agent that runs its own logic and produces structured output. Each edge is a conditional edge, and it decides which node to route the flow to next, based on the output of the previous node.

The LLM itself works on probability, so in the graph it is only responsible for making judgments, in other words, updating the state. What really decides how the workflow runs is a traditional scripted process defined by LangGraph. Because the script runs in a very deterministic way, the whole process never drifts.

By now, you have probably already seen where this is going. Yes, to let the harness also carry out the workflow accurately, I decided to add a graph based script engine to AIDLC. And at each stage, I let the LLM output a structured state to guide each step the script engine takes.

Now that the logic behind this is clear, let me walk you through how I designed this script engine.

I split the design of the engine into two phases: the authoring phase and the runtime phase. The authoring phase is mainly about how to define the workflow, and the runtime phase is about how to use the workflow.

Step one: define the workflow metadata

Whether it is AIDLC or an SDD framework like OpenSpec, they both actually record the definition of the whole AI coding workflow in prose, inside skill files or prompt files. The LLM then follows this prompt definition to move agents and process nodes along the flow.

This creates a problem. The LLM can pull information out of text, but a script program cannot. Neither Python nor JS can understand the meaning of text without help from an LLM.

One way to do this is like LangGraph's API, where the whole workflow gets defined directly in code. When a new development task comes in, it gets routed strictly according to the code that was already written.

But this method has a big downside: it is almost impossible to customize. I want to turn AIDLC into an open framework, which means it also allows users to modify the workflow themselves. And while using it, I also want to be able to adjust the implementation details of the workflow. If every change means I have to touch the script engine, that is too risky.

So I thought, could we use a structured YAML text file to define the workflow, the way crew.ai does?

But I also did not want to throw away the workflow definitions already in the existing Markdown files and start a whole new spec from scratch. That would mean every time I adjust the workflow, I would need to change both the Markdown file and the YAML file.

So I came up with a solution. I kept the existing 14 stage Markdown prompt files of AIDLC unchanged. But at the top of each file, I added a frontmatter. This means I put a block of config information at the start of the Markdown file that only the script reads. Then I pulled all the workflow related definitions out of the prompt and put them into this config block.

Here is a typical frontmatter, using the requirements-analysis.md file as an example:

---
slug: requirements-analysis
phase: inception
execution: ALWAYS
condition: Always executes with adaptive depth — every request needs its intent and requirements assessed; depth (minimal/standard/comprehensive) scales with clarity, complexity, and risk
gate: approve-continue
produces:
  - inception/requirements/requirements.md
  - inception/requirements/requirement-verification-questions.md
consumes:
  - artifact: inception/reverse-engineering/*
    required: true
    conditional_on: brownfield
  - artifact: inception/product-design/product-design.md
    required: false
requires_stage:
  - workspace-detection
  - reverse-engineering
  - product-brainstorm
depth: adaptive
scopes:
  classic: EXECUTE
  bugfix: EXECUTE
  refactor: EXECUTE
  security-patch: EXECUTE
  infra: EXECUTE
  express: EXECUTE
---

This frontmatter looks pretty complex, but it is actually very simple to understand:

Keys like slug, phase, execution, condition, gate, produces are all metadata. They define the conditions needed before the current node runs, what phase it is in, what it produces, and so on. The script engine uses these keys to check if the current node is working correctly when it routes the state.
consumes and requires_stage define which upstream nodes the current node depends on, and which states of the upstream nodes it needs to consume.
depth and scopes define which workflows the current node shows up in, and how deep the branch of the graph goes. This makes it clear exactly when a Markdown file needs to be loaded, instead of loading every single Markdown file right at the start.

I also wrote a stage-contract.md document under the reference/common directory of AIDLC. This document works as a meta spec, and it records in detail what each key in the frontmatter means and what values it can take. So the next time I adjust the workflow, or add or remove a stage, the LLM can use this document to help me write the frontmatter correctly, and it can update the dependencies between the existing frontmatters without making mistakes. This is very handy.

Step two: set up multiple workflows based on scenario

Next, let me focus on the scopes key. This key is used to let AIDLC generate different workflows for different scenarios. Yes, after bringing in the new script engine, AIDLC no longer has just one single workflow. Instead, it now has 6 completely different workflows.

What is the benefit here?

In the original AIDLC V1.0, there was only one workflow, and all 14 stages were marked with different activation conditions. Depending on whether it was a new project, how complex the project was, whether it was a bugfix or a feature request, and so on, it was decided which stages would run and which would be skipped.

But whether a stage would run or get skipped, the prompt defining it would still get loaded into the context as soon as the skill loaded. This wasted a lot of tokens.

So this time I split AIDLC's workflow by business scope, from one scope into six. Each business scope maps to a different set of stages to run. When the user types a prompt and this triggers the aidlc-workflows skill to load, the LLM figures out which scope the current iteration falls into, and it only loads the Markdown files it needs.

As your project moves through different stages, the system also adjusts which scope it picks on its own, instead of sticking with the same one scope forever.

Here is an example: say your project starts out as just an MVP you want to build quickly to test your idea in the market. In this case, AIDLC decides this is an express scope, so it only loads the fewest stages needed to quickly finish a product prototype.

Then, as your project wins over users and slowly grows into a product running stably in production, AIDLC's workflow uses the audit log and past spec files to shift the scope to classic. At this point, optional stages like user stories, non functional requirements, security, and scalability all get loaded in, helping you polish your product step by step.

Step three: turn the metadata into a workflow graph

As I mentioned earlier, a script engine cannot possibly build a workflow at runtime by reading natural language text. So we need a descriptive syntax to let the engine run according to a definition made ahead of time.

We used frontmatter to define AIDLC's metadata at each stage. We also used scope to sort out which stages should be used in which scenarios. Now, just like crew.ai, we need to use a structured syntax to turn these workflows into predefined workflows.

The approach here is actually pretty simple. I did not generate the workflow dynamically at runtime (meaning, while the user is using AIDLC). Instead, I generate the workflow graph while developing the AIDLC skill.

I placed a generate.py script under aidlc-workflows/scripts. Every time the workflow definition changes, you can have the harness run the generate.py script to regenerate the graph file.

The generate.py script also supports a --check flag. Every time the AIDLC skill gets updated, you can use this flag to run an integrity check. I also set up a GitHub CI process that automatically checks the integrity of the graph every time code gets committed. This is very handy.

In the end, the generate.py script produces a graph in JSON format, stored under the aidlc-workflows/scripts/data/ directory. This graph defines what the workflow architecture looks like under each scope, what its entry conditions are, what it is responsible for, what it outputs, and so on. At runtime, the script engine reads this graph and uses it to build the final workflow.

Step four: use the script engine to run the workflow precisely

Now that we have talked about how the workflow gets defined, let's talk about how I use the script engine to make sure the workflow runs precisely.

Other frameworks also use scripted mechanisms to make sure the workflow runs precisely, but they all need hooks from the harness to listen to the different states of the workflow as it runs. This often means an SDD framework needs to work with more than twenty different harnesses, and it needs a custom plugin for each one.

But in an enterprise level AI coding environment, this approach does not work very well, because we always build our own harness on top of an open source harness. So I would rather use a workflow framework that is not tied to any specific harness.

The AIDLC skill I built was designed from the start to be harness agnostic. It still follows the AgentSkill spec, and it keeps the script engine as a CLI script stored under the skill directory's scripts folder, with the script named engine.py.

The nice thing about this is that you do not need to care at all about how this script is built or used. You just copy the skill directory into your project's root folder like before, and then you can use it.

Let me give a quick intro to how the engine.py script works. As a CLI script, engine.py's most important commands are these:

init. This command sets up a state file when the workflow starts. All the different states of the workflow get recorded in this file later on, so the script engine can use the state machine to route each node of the workflow.
next. This command reads the state file, figures out which stages are already finished and what those finished stages produced, and uses this to decide what the next node is and routes to it.
report. After each stage finishes, this command gets used to update the state file. This way, whether you are continuing after the context got compressed or starting a new session, you can always pick up from the last finished stage.
status. This reads the global workflow properties set in the state file. For example, which scope is in use right now, whether optional stages are turned on, whether team collaboration mode is turned on, and so on, can all be read through this command. This way, every time a session resumes and reloads aidlc-workflows, there is no need to ask the user the optional questions all over again.

Step five: use a state file to precisely record the workflow state

As I mentioned earlier, the script engine I designed is basically a graph engine based on a state machine, similar in principle to LangGraph. So besides the graph file that defines the workflow, the state file is another very important file.

This file gets generated each time a new workflow starts. It still uses the original aidlc-state.md file from AIDLC V1.0, but this file has been heavily reworked, and now it is split into two parts.

The first part is the workflow related config. Whether it is a new project or an old project, which scope is in use, which stages need to run, where the artifact documents are stored, which extended features are turned on, all of this gets recorded here. This way, whether it is a new session or picking up from a break in the session, there is no need to scan through the artifact documents one by one. You just read this file and can pick up the process from where it left off.

The second part is the task checklist that engine.py generates based on the config. While the workflow is running, the engine follows this checklist strictly, and after finishing, it goes back to this checklist to update the task status.

The script engine uses the two XML tags <!-- BEGIN ENGINE-STATE> and <!-- END ENGINE-STATE> to mark the content of the task checklist. Only the script engine is allowed to change the text wrapped inside these tags, not even the LLM is allowed to edit it directly.

Also, every time the task status is updated, a sha256 hash gets generated for the whole checklist. If the sha256 hash changes during a run, this means the node status has been tampered with, either by a human or by the LLM. The script engine will then raise a warning, and it will rebuild a correct checklist by working backward from the artifact files that were already generated. This greatly reduces the chance of workflow drift during a long running task, or cases where the LLM planned a task but never actually carried it out.

# AI-DLC State Tracking
## Project Information
- **Project Type**: Greenfield
- **Start Date**: 2026-10-08T04:10:57Z
## Workspace State
- **Existing Code**: No
- **Reverse Engineering Needed**: No
- **Workspace Root**: D:\Documents\PythonProject\b15-dogfood2-chess
...
<!-- BEGIN ENGINE-STATE | do not hand-edit — maintained by scripts/engine.py -->
State Version: 1
Engine: aidlc-workflows/scripts/engine.py
## Stage Progress
### inception
- [x] workspace-detection
- [S] reverse-engineering
- [x] product-brainstorm
...
## State Digest
sha256: 33cc76d5ae995526968640649c234282291b00e42949b40c826722fc5ee5ac02
<!-- END ENGINE-STATE -->

Alright, that covers the whole implementation of the script engine. You might feel a bit anxious thinking this is so complex, do I need to spend time learning a whole new framework again?

Actually, no. This new script engine, just like the aidlc-workflows skill itself, is harness agnostic. You just drop the skill into your project's root folder and it runs on its own. You do not need to worry at all about how to use this skill.

Next, let me use a simple project to show you how the script engine works within a workflow.

Demo the Script Engine with a Small Project

I will use a small request, "build a bookkeeping app", to show you how this script engine works.

Since this is just a demo project, I used a one sentence request. But if you want to use this in a production project, it is best to prepare a full product design document ahead of time, writing out clearly what features your product should have. Or you can first use OpenCode's plan mode to talk through your idea with AI, and write it down as a design document, then use build mode to start the aidlc-workflows and kick off the development process.

Since this starts from a new session, once I submitted my development intent to OpenCode and aidlc-workflows finished loading, the script engine first ran the status command to find out what state the workflow was currently in. Of course, the result was that this is a brand new, empty project.

So it used the init command to set up the new workflow.

After each stage finishes, the script engine uses the report command to update the workflow state. You can see that the LLM is no longer involved in moving the workflow forward at all. This is all handled by the skill calling the CLI.

That is pretty much it. The script engine compiles every node that the whole iteration needs to move through into a flow graph, and no matter how long the session stretches, it never drifts off track.

All you need to do is, at the approval gate set up for each stage (the gate configured for that stage), take a quick look at what it produced and give it a thumbs up. Once it passes review, the engine calls the next command to move you forward to the next stage.

And at every important point, like writing a document, calling an outside tool, or moving between states, the script engine uses the park command to leave a note. So even if your workflow gets cut off unexpectedly for whatever reason, the AI can pick back up from the spot where the last note was left.

If you start a new session to pick up a development process that was not finished before, the script engine also uses status first to read the current state and continue from there. There is no need to ask the user to choose again, and no need to scan through every single artifact file that has already been saved. This saves a lot of time.

That covers the demo of the core features. As you can see, while the script runs, every step follows the predefined process exactly, and even in a long session, nothing drifts off track, because the state file keeps everything in line.

You also do not need to give any special instructions. Just tell the AI your intent normally, and you do not need to worry about how the workflow is actually built.

Conclusion

That is the story of how I used a script engine to make AIDLC run exactly according to the predefined workflow. This script engine borrows a core idea from Amazon's AIDLC v2.0: "judgment to the LLM, precision to the tool, decisions to humans." It also draws on the design wisdom of traditional agent workflow frameworks like LangGraph and Crew.ai.

The new aidlc-workflows skill, now with the script engine, has been running as a trial in my team for more than two months. The biggest thing I have noticed is that the workflow almost never drifts off track because of a long session anymore, and this precise execution of the workflow has further raised the quality of the code produced by AI coding.

I enjoyed writing this article. A lot of people say that AI technology moves so fast that whatever you learn today might be useless in just a few months. But we do not need to be too pessimistic about this. Take the solution shown in this article as an example. Even though the technology keeps changing, the principles behind the technology can still help you solve problems you have not even seen yet.

My story of improving AIDLC is not over yet. In my next article, I will walk you through how the AIDLC workflow can help you start from a "one sentence wish" and iterate step by step, eventually growing into a large, sustainably run project. Stay tuned.

Thanks for reading and subscribing. You can find the source code for this article at the end of the post, and try it out yourself. If you have any questions, feel free to leave a comment anytime, and I will reply as soon as I can.

How I Use OpenCode, Oh-My-OpenCode-Slim, and OpenSpec to Build My Own AI Coding Environment

Ride the wave of AI coding, don't get swept away by it

dataleadsfuture.com

From OpenSpec to AIDLC: How I Improved My Team's AI Code Quality

No new commands to learn, just pick it up and use it

dataleadsfuture.com

I spent over a month reworking the entire team's AI Coding workflow. We brought in Amazon's aidlc-workflows and adapted it to fit our own needs. Both the team's AI development efficiency and code quality improved significantly.

Peng Qian — Wed, 09 Sep 2026 03:44:46 +0000

Peng Qian

Sep 9

From OpenSpec to AIDLC: How I Improved My Team's AI Code Quality

#ai #aws #development #productivity

17 min read

From OpenSpec to AIDLC: How I Improved My Team's AI Code Quality

Peng Qian — Wed, 09 Sep 2026 03:40:57 +0000

No new commands to learn, just pick it up and use it

By this August, our team had been writing code with AI for more than half a year. The biggest thing I noticed during this time was that our development speed went up, but code quality stayed pretty rough. Development often took just half a day, but hunting down bugs could take several days.

So recently I spent more than a month restructuring our team's AI coding workflow. I replaced OpenSpec with the AIDLC workflow, using a more detailed software development process and stronger team collaboration. Code quality finally jumped up a lot.

In today's article, I want to tell you how we did it.

This article was originally published on my personal blog, Data Leads Future, where you can find the source code at the bottom of the original post. I'll also keep updating content there and am happy to answer any questions you might have.

Introduction

AI coding has been around for more than a year now. People's focus in this field has slowly shifted from which model works better and how much it boosts efficiency, to how we can make sure the code AI generates is actually good quality.

I recently noticed something. On social media, people talk more and more about questions like "how do I actually make sure my AI coding output has good quality" and "who should be responsible for code AI writes."

If you asked me six months ago, I would have said the best answer to this question was SDD (Spec Driven Development). Based on rule frameworks like SpecKit and OpenSpec, you first talk things through in a question-and-answer style to nail down the requirements and implementation rules. Then you feed the spec files to the LLM as a prompt, and the LLM writes code strictly following those specs. This seemed like the best way to do AI coding.

I even wrote a few articles about tips for using OpenSpec.

It wasn't until I rolled out my method to the whole development team that I realized something. SDD works pretty well for small projects. But once your project gets big, spans several years, and needs collaboration across multiple teams, OpenSpec just doesn't hold up.

What Actually Went Wrong with OpenSpec

When I say it doesn't hold up, let's look at what actually went wrong with SDD frameworks like OpenSpec.

Using it got way too complicated

How many commands from OpenSpec's documentation on GitHub do you still remember? Do you know exactly when to use explore and when to use propose?

When I rolled out OpenSpec to my team, I wrote a whole document explaining when to use each command, and I told everyone to follow the workflow I laid out.

Things still went sideways. Should explore come before propose or after? Why can't I just jump straight to the plan agent? I bet you can't answer that either, right?

Because the commands and their use cases got so complicated, everyone on the team ended up using OpenSpec differently. Some people even used OpenSpec just for show at the start and switched to pure vibe coding afterward. This shows that the extra learning cost didn't really pay off for developers.

It never captured the original intent

Speaking of the difference between the explore command and the plan agent, this brings up another problem. The spec files OpenSpec writes never save the user's original intent or original requirements, and they never keep the conversation the user had with AI during the plan phase.

Because of this, when I reviewed spec files written by another team member, I often felt completely lost. Why was this user story written this way? What problem was this method design actually trying to solve?

Give it enough time, and even the developer who wrote the code might forget why a feature got designed a certain way.

Once you lose the original intent, your project drifts further and further from its original goal with every iteration.

It's hard to get the right level of detail for requirements

OpenSpec's explore mode, or the brainstorm mode in other SDD frameworks, is honestly pretty powerful. This can pull you straight into the trap of wish-based coding without you even noticing. You start hoping that a single sentence is enough, that OpenSpec will chat with you and break your requirements down step by step, then gradually build out a complete product for you.

But AI can't do that yet.

The current generation of LLMs is really good at finding shortcuts. If you describe a vague goal for your project and expect OpenSpec to break it down into fine-grained requirements and iterations, that rarely works. What you get in the end is just a demo with the main features and nothing else. All the detailed implementation is missing, so it's really just a half-finished product that can't go live in a production system.

So experienced developers know that when doing SDD development, the best move is to break the product's features into small pieces and let OpenSpec iterate on them round by round. For example, build the project skeleton and tech stack in the first round, then build the login and authentication system in the second round, and so on. Only this way can a project slowly get polished into a real product.

But it's really hard to control how fine you break these requirements down. Break them too coarse, and your project turns into a demo. Break them too fine and your development speed drops. Sometimes the developer hasn't even thought of some necessary features at the start, so details easily get missed.

Documentation stops matching reality

Next up is the documentation consistency problem. Your team member starts by using OpenSpec to write out the spec docs, then moves on to coding, adjusting the implementation along the way. But because they never explicitly called an OpenSpec command again, none of those later adjustments ever get written back into any document.

There's another situation too. While generating rule artifacts, you notice a problem in tasks.md and fix it, but unless you specifically ask, AI won't go touch design.md on its own.

As your project grows bigger with each iteration, this kind of inconsistency shows up everywhere. Eventually, the spec files completely lose their value as a reference. Then you end up with a pile of messy code.

You never know when to start the process

I once asked a teammate why they still chose vibe coding even though everyone knew SDD could improve code quality.

One reason they gave me was that the commands map to development phases in such a complicated way that they genuinely didn't know when to kick off the process.

Here's an example.

Right after you use apply to finish writing code, you suddenly find a bug in what got generated. Do you ask AI to fix it directly, or do you go run the proposed artifact flow first?

Or say you're in the middle of fixing a bug and suddenly get a great idea to tweak an existing feature, or maybe you just want to delete this chunk of code and rewrite it a different way. Do you run the OpenSpec flow first, or just change it directly?

Team collaboration falls apart

Every open source framework like OpenSpec assumes the same thing. With AI's help, each of us becomes a super developer who can handle everything from start to finish alone.

But everyone on our team has a clearly defined role. Modern business has gotten complicated enough that no single person can handle everything alone anymore.

After you finish writing the requirements analysis doc and user stories, shouldn't you check them with the product team? At the very least, you need to align on how metrics get calculated, right? The same goes for architecture design and coding plans. Shouldn't you run those docs by other developers or an architect? What if the design approach has a mistake somewhere?

But the OpenSpec framework ignores this kind of problem completely. From the moment you start using propose to write spec artifacts until you finish coding, the whole workflow only happens in your own environment. Nobody else looks at the docs you wrote unless you go show them yourself. OpenSpec also makes it really hard to plug in quality gates or review mechanisms for control.

Sure, even the best frameworks have some flaws. But the problems with SDD frameworks like OpenSpec make it much harder for them to succeed in enterprise development teams.

What's My Solution

So how did I solve this whole mess?

At first, I thought like most programmers in the AI era. Build a new wheel myself, and let AI write a brand new workflow under my guidance.

But I quickly realized this wouldn't work. A new development process that hasn't been tested by a lot of development teams just turns into another AI toy. It doesn't have the reliability you need for an enterprise development environment.

So I remembered a piece of news from six months ago about Amazon AWS's AI coding workflow.

Amazon seemed to run into the same problem we did. Their unreliable AI development process caused disasters in production. So they required that any code written by junior or mid-level engineers get approved by another role on the team. Hmm, this matches exactly what we ran into.

I figured that at the time, this response was probably just a temporary fix. Six months had passed, so they must have come up with a more systematic, more engineered solution by now.

After some digging, I found the solution they came up with: aidlc-workflows.

Note: Amazon already released version 2.0 of aidlc-workflows, but this article is still based on version 1.0 with some custom modifications. I think version 1.0 is lightweight enough and easy to extend, which makes it more convenient to use. Try the customized version I share at the end of this article.

What is AIDLC

AIDLC stands for AI Driven Development Life Cycle. It's a software development process that corresponds to the traditional SDLC, or Software Development Life Cycle.

The traditional SDLC breaks enterprise-level software development into six or seven main phases: planning, requirements analysis, design, development, testing, deployment, and maintenance.

AIDLC builds on top of these seven phases and adds two new capabilities: dynamic workflows and dynamic team collaboration.

How does it pull this off?

First, AIDLC doesn't just inherit SDLC's seven phases. It also groups these seven phases into three big stages.

The Inception stage handles workspace detection, conditional sub-stages, and workflow planning. This stage answers the questions of what and why.

The Construction stage handles sub-stages like design, implementation, building, and testing. This stage answers the question of how.

Here's what it looks like.

It looks like there are a lot of sub-stages to go through, but don't worry. Not every new requirement goes through all of them. As the image shows, the ones marked green always run, while the ones marked yellow only run when certain conditions are met.

What decides which ones run and which ones don't is what AIDLC calls its dynamic workflow planning capability.

What is dynamic workflow planning

When we bring up a new development requirement, AIDLC works differently from traditional SDD frameworks that first chat, then write docs, then implement. Based on the current project environment and the choices the user makes during the conversation, AIDLC branches into different conditional paths, and each branch loads a different subworkflow. Complex projects load more subworkflow stages, while small projects load simpler ones.

Here's an example.

The first time AIDLC loads, it checks whether the current project environment is brand new (Green Field) or already exists (Brown Field). If it's an existing environment, it loads the reverse-engineering workflow to analyze what the existing code already does. If it's a brand new environment, it skips the reverse-engineering subworkflow entirely.

When we bring up a new requirement, AIDLC checks whether it affects the product's end users. If it does, it loads the user-stories workflow to do user story analysis. If your requirement is just a non-functional requirement, or purely a frontend page development task, it skips user stories and moves straight to the next sub-stage.

AIDLC also keeps a file called aidlc-state.md. Besides tracking which stage the workflow currently sits at, this file serves another purpose too. If you want to do wish-based development, AIDLC breaks down your one-sentence requirement, pulls out the sub-requirement that needs the most urgent action, and kicks off the workflow for that one. The other sub-requirements get recorded in aidlc-state.md and wait for the next round of the workflow to start. This solves the problem of requirement granularity.

AIDLC's core workflow works like a butler that always stays in the conversation. When something you say or the project's state triggers a condition, the butler pulls out the matching subworkflow document from the cabinet and lets that sub-process take over. This way, you don't need to remember which command to use when. The butler figures it out for you. You don't need to worry about learning new commands you can't remember, and you don't need to think about when to start a process either. The butler handles all of that.

What is dynamic team collaboration

AIDLC's dynamic team collaboration has two parts: requirements analysis logging and approval gates.

Unlike traditional question-and-answer conversations that mostly keep the chat history in context, AIDLC starts conversations and asks the developer questions whenever the sub workflow calls for it, at any point in the process. Every question and every choice the developer makes gets recorded in a file called {current-phase}-questions.md.

At the end of each sub-stage, if you want to tweak the output of the current stage or you have some new thoughts to share, those tweaks and AI's response get organized and saved in a file called audit.md. This solves the problem of the original intent never getting recorded.

If you work solo, you just need to check that all the documents look good and reply with "continue." But if you work on a team and you need another role to review the documents for you, you can commit the code through git and send it to your teammate for review.

Your teammate's review notes and marks get recorded in audit.md, and then that gets sent back to you. Your instance of AIDLC only moves to the next stage once it sees the approval mark for the current stage. audit.md only supports incremental updates and never gets edited, so you always have access to every change and every review record.

AIDLC also lets you extend the workflow using the extensions folder. You can set which key stages need review from which roles, and you can set every round of review to log the reviewer's info for future reference. So, compared to OpenSpec, AIDLC puts a lot more emphasis on team collaboration.

OK, that covers the details of what AIDLC can do. I bet you're eager to hear how this works out in our team's actual development.

How We Put AIDLC to Work on Our Team

Since everyone cares about different things, going through my specific project won't give you much to work with. So in this section, I'm not going to walk through a specific project. Instead, I want to walk you through the local customizations I made based on what our team's development actually needed.

To make things easier to use, I already rewrote all these customizations as Skills. You just need to grab the source code at the end of this article, put it in the right place, and let your coding agent load it. It kicks in automatically after that.

Turning AIDLC into a Skill

AIDLC's core lives in two folders. The aws-aidlc-rules folder holds the core workflow definitions, and the aws-aidlc-rule-details folder holds the subworkflow files that load on demand.

By default, it supports Amazon's own coding agent Kiro. For other common coding agents, the setup steps the official site gives you get so complicated that nobody has the patience to read through them.

But at its core, AIDLC is really just made up of a dozen or so Markdown files. That means you can completely turn it into a Skill instead.

The transformation is really simple too. Just create a folder called aidlc-workflows under .agents/skills, copy aws-aidlc-rules/core-workflow.md into that folder, and rename it to SKILL.md. Then, following the Agent Skills spec, copy every file from aws-aidlc-rule-details into the aidlc-workflows/references folder. Finally, have your coding agent fix up all the file paths so they point to the right place.

Extending the AIDLC workflow

As I mentioned earlier, AIDLC's workflow is really easy to extend. Beyond the sub-workflows already customized for the existing inception, construction, and operations stages under the reference folder, it also supports the extensions folder, which lets you add optional custom workflows that load dynamically. Testing, security, and resilient deployment all fall into this category.

An extension workflow usually splits into two files: the core workflow file {workflow-name}.md, and a lead-in file with an opt-in.md suffix called {workflow-name}.opt-in.md.

The {workflow-name}.opt-in.md file contains a question that needs clarification from the user. The answer to that question decides which stages the extension workflow {workflow-name}.md applies to.

The opt-in file loads during the requirements analysis stage, and based on how the user answers, it decides whether the extension workflow loads later on. If your custom extension workflow only has a {workflow-name}.md file and no opt-in file, that workflow always loads. This mechanism makes sure multiple extensions can load dynamically, so you can maintain endless extensions without blowing up your context.

Alright, now that you understand how AIDLC's workflow extension mechanism works, let me walk you through a few extensions I customized.

Keeping documentation consistent

This extension requires AIDLC to update every related workflow document whenever code changes happen. This keeps the docs consistent with the code, so you never run into the SDD problem where the code changes but the spec docs stay out of sync.

Separating approval from execution

In the default AIDLC flow, once you approve a stage, the workflow automatically moves on and keeps running.

That's fine if you work solo, but it breaks down when you need to review a colleague's document. Say you're the product manager. You can't just let AI generate code on your own computer the moment the requirements doc gets approved, right?

So I split the meaning of "approved" into two separate actions: approve and continue. Once you approve the documents at a certain stage, the workflow doesn't automatically move to the next step. Instead, you should send the docs over to whoever handles the next stage. Once your colleague sees that you approved the docs, they say "continue," and only then does the workflow keep going.

This split keeps approval and action separate, making sure different roles handle different stages of the software development process. It lets each teammate's expertise shine where it matters most.

Signing off on the audit trail

This extension solves the problem of who should get held responsible for code AI writes.

In the default flow, AIDLC logs every round of conversation between the user and AI in audit.md. This makes it easy to audit where a requirement came from and to trace the approval history at each stage.

But the default audit.md file never records who raised the requirement or the change, and it never records who approved the documents. When your project needs team collaboration, it gets hard to figure out exactly who to talk to just by reading through audit.md's history.

So I used this extension to modify audit.md and added two keys: User and Email. I use git config user.name and git config user.email to fill in these two keys. This way I always know exactly who each history record belongs to.

Using the question tool

The original version of AIDLC is a workflow module built for Kiro, so it doesn't play that well with other AI IDEs. The questions it asks users get written into a file called {phase-name}-questions.md, and it expects users to go into that file to answer and record their responses.

But ever since I started using AI IDEs, I haven't touched traditional editors like VS Code in a long time. I really don't want to open up a whole IDE just to answer a few questions. That's way too much hassle.

Since I mainly use OpenCode, I built an extension that has AIDLC directly use OpenCode's question tool to ask the user right after generating the questions, then writes the user's answers back into the document. This way, I never have to leave OpenCode to go edit a file in another IDE.

Testing and other best practices

These next few items are default extensions in AIDLC, not something I built myself, but I think they're worth talking about.

Why did we pick Amazon's AIDLC instead of yet another open source SDD framework? Besides the fact that this workflow got tested through the software development process at a huge tech company, we also wanted to learn from the software engineering experience of a top-tier tech company through AIDLC.

And AIDLC really lives up to that. Under the extensions folder, the testing, security, and resiliency subfolders each hold this company's best practices for software testing, security, and continuous integration and deployment.

Here's an example.

In the past, when AI wrote unit tests for us, it would sometimes change the source code or tweak the test afterward, just to make the coverage numbers look good. Basically, AI wrote the exam questions and then changed its own answers to cheat the metrics.

But AIDLC does things differently. It requires using Property Based Testing, or PBT. Instead of checking a single fixed input, PBT randomly generates a huge batch of input conditions, making it really hard for the code to "memorize the answer" ahead of time. AI has no idea what input comes next, so it can't tweak the code to game the test.

For a lot of startup teams, these practices are valuable lessons that are hard to come across in everyday work. If you get the chance, I recommend turning on the related options and giving them a try.

Conclusion

That covers how I used AIDLC to rework our team's AI coding process.

Based on how we've been using it, this workflow really works well. There's basically no learning curve, and you can pick it up and start using it right away.

And since this comes from the best practices of a major tech company, this workflow puts a lot of focus on dynamic workflows and dynamic team collaboration. It's really convenient for customizing based on what your team's development process actually needs.

It also makes it easier to clarify what each team member is responsible for at every stage of development. If something goes wrong in production, it's easier to trace the root cause, figure out who's responsible, and get it fixed.

One thing worth noting is that this workflow really emphasizes a software lifecycle management style of development. The questions that need clarifying during the conversation get a lot more technical too. You might need to learn more software engineering knowledge to fully master this workflow. But software engineering is basic knowledge every developer should learn anyway, so I don't think this is a big deal.

This workflow gave our team a huge boost, both in development efficiency and in code quality. So I recommend giving it a try yourself. If you run into any problems along the way, leave me a comment, and I'll answer as soon as I can.

Thanks for reading. I'm Mr. Qian, and I focus on researching AI agents for enterprise applications and AI coding. Follow my personal blog Data Leads Future to get my latest updates.

If you found this helpful, feel free to share it with your friends too.

This article was first published on my personal blog, Data Leads Future, where you can find the source code at the end of the original post.

I spent over a month reworking the entire team's AI Coding workflow. We brought in Amazon's aidlc-workflows and adapted it to fit our own needs. Both the team's AI development efficiency and code quality improved significantly.

Peng Qian — Wed, 02 Sep 2026 04:00:56 +0000

Peng Qian

Sep 2

How I Use Aidlc to Improve My Team's AI Code Quality

#ai #programming #coding #productivity

7 min read

With the same Kimi K3 quota and similar quality, you can get more done. This post outlines how I optimized my OpenCode setup to reduce Kimi K3 costs.

Peng Qian — Mon, 03 Aug 2026 08:39:47 +0000

Peng Qian

Aug 3

How I Cut Kimi K3 Costs in OpenCode

#ai #vibecoding #coding #programming

5 min read

How I Cut Kimi K3 Costs in OpenCode

Peng Qian — Mon, 03 Aug 2026 08:39:12 +0000

Better code quality, but spend less money

Introduction

Last week, I burned through 7 days' worth of quota in a single day while using the Kimi K3 model on Kimi's Allegretto plan.

Kimi K3 is genuinely great. Its performance is on par with Claude Fable 5 and GPT 5.6 SOL, so I ended up going full throttle with it all day long.

But the cost is ridiculous. It runs way higher than GLM-5.2, DeepSeek-V4, or even Kimi K2.7. For someone like me who was spoiled by the cheap API of DeepSeek-V4, that was not acceptable.

So I started optimizing how I use OpenCode. The goal was to do more with the same Kimi K3 quota while keeping quality about the same.

After a few days of work, the results are pretty solid. The Allegreto plan now covers a full week of development for me. No more sitting around two days out of five waiting for the weekly Kimi K3 quota to reset.

If these methods work for me, they should work for you too. So this article is a quick write-up of what I've done, and I hope it helps you lower your Kimi K3 costs in OpenCode.

All the source code mentioned in this article is at the bottom. Feel free to grab it.

This article was originally published on my personal blog Data Leads Future, where I'll keep updating this content. You can also grab the source code for free over there and ask me anything you like.

Pick the Right Provider

The most fundamental way to cut costs is picking the right provider. The official Coding Plan is the best option. Based on various reports, the third and fourth tiers of the Coding Plan offer dozens of times more value per dollar than the API at the same price. That's a great deal.

Besides the official Coding Plan, if you'd rather pay per use or call a third-party API, you can just use open platforms that support Kimi K3, like Novita.ai (which offers ultra-low-latency endpoints and generous free credits for new users) and OpenRouter. The setup and how it works are the same.

Since I already purchased the official Allegreto plan upfront, I'll use the Coding Plan models as the primary example throughout this article.

Pick the Right Model and Thinking Level (Variants)

Pick the right model

The Coding Plan gives you access to two models: K2.7 Code and K3. K3 requires Allegretto or above, and only the K3 model supports 1M context length.

This week, Kimi also released a K3 model with 256K context, with the model ID k3-256k. At the same time, the official docs confirmed that the standard K3 model consumes twice the quota of k3-256k. That's probably why I burned through a whole week's quota right out of the gate. Without a second thought, I switched my default model to k3-256k.

You might wonder: since I'm used to DeepSeek-V4's 1M context, will 256K be enough?

I don't think you need to worry too much about that.

The 1M context mainly helps your cache hit rate stay high as conversations get longer. But context rot is still a real problem as the context grows. So if you've ever felt like DeepSeek-V4 gets dumber after a long session, your instinct is right. That's context rot at work.

On top of that, we normally use frameworks like OpenSpec for SDD (Spec-Driven Development). All the plans and specs worked out earlier with the model get saved as files on disk. Whether you use the /compact command or start a new session, the model reads context from those files. The message history doesn't need to be that long.

Then there are situations where you need to scan a large codebase or pull in a lot of information from the web. For those cases, we use sub-agents running in separate sub-sessions to handle the research, then return only the key findings to the main session. That approach cuts down context usage a lot.

All things considered, 256K context is plenty for now. For the Plan and Build agents, just use k3-256k directly.

If you're using the API from Novita.ai, it's even simpler. Just use Kimi K3 straight up.

Pick the thinking level

For a long time, Kimi models felt slow. That's because before K3, Kimi didn't support the reasoning_effort parameter. Every call defaulted to maximum thinking, so each request took forever to finish.

The K3 release added support for reasoning_effort, with three levels: low, high, and max. But when the model first launched last week, only max was available. That meant every call generated massive thinking tokens through a long chain-of-thought process, which burned through a huge amount of token budget.

Good news: starting this week, both K3 models support low and high. If you're setting up Kimi K3 in OpenCode for the first time this week, the default thinking level is High. If you configured Kimi K3 last week, make sure you change the thinking level from Max to High.

If you care more about code quality than cost, or you're doing complex research and don't want lower thinking intensity to hurt your results, there's a middle ground. Use Max thinking in the Plan agent for architecture planning, then use High thinking in the Build agent for code execution.

One thing to watch out for here is that, according to the official docs, switching the reasoning_effort value invalidates the context cache.

Right after the switch, the model immediately refills the cache using your existing message history, which costs extra tokens. The official recommendation is to open a new session before switching reasoning_effort, so you avoid paying to refill old messages into the cache.

There's a more elegant solution though. Set up a dedicated sub-agent with Max thinking, specifically for architecture decisions and hard problems. I'll cover that in the next section.

What's next?

How to configure the built-in explore and general agents in OpenCode to significantly cut down on input costs.
How to save on output costs by setting up the executor and architect agents.
A quick walkthrough on cache configuration for the coding agent.

If you're interested, feel free to click on Data Leads Future to read the full article.

The concept of Loop Engineering has been getting a lot of buzz lately, so I decided to give it a shot in OpenCode. The results were surprisingly good:

Peng Qian — Thu, 16 Jul 2026 07:41:44 +0000

Peng Qian

Jul 16

How I Built a Fully Automated Coding Loop in OpenCode

#ai #programming #coding #llm

4 min read

How I Built a Fully Automated Coding Loop in OpenCode

Peng Qian — Thu, 16 Jul 2026 07:41:10 +0000

Introduction

If you've been following the AI agent space recently, you've probably heard the term Loop Engineering. Claude Code and OpenClaw both mention it.

But nobody really explains what it means.

Until Andrew Ng posted a clear breakdown of what Loop Engineering actually is. That post gave me the direction I needed to build it inside OpenCode.

What Andrew Ng Says About the Coding Loop

Andrew Ng's explanation centers around this diagram:

Three loops, simply put:

The first loop is the code agent's implementation loop. You give the agent a product spec and a measurable target. The agent starts building features on its own, runs tests, and keeps iterating until every requirement in the spec is met.
The second loop is the engineer feedback loop. Here the engineer acts as QA for their own product. They test what the coding agent built, and check if it matches their vision. If something is off, they write a new spec and kick off another round in the first loop.
The third loop is the external feedback loop. Once the engineer is happy with the product, it goes to the open-source community or gets handed to a product team. Real user feedback comes in. The engineer collects that feedback regularly, feeds it back into the engineer feedback loop, and from there back into the code implementation loop.

All three loops keep running. With AI in the mix, they push the product forward until it gets to where it needs to be.

My Attempts

Following Professor Andrew Ng's breakdown, I gave it a try in OpenCode. I built a /goal command that lets users just type in what they want the AI to do, and the AI will kick off a coding loop to get it done automatically.

I tested this command out and honestly, the results were way better than I expected.

Here are some of the test scenarios I ran:

1. Write a Fibonacci script

This test checks whether the agent picks the best algorithm. The prompt is:

/goal Write a Fibonacci calculation script with the best possible performance.

2. Build a Tower of Hanoi web game

Everyone knows this game. You could honestly just prompt an LLM directly and get it built. But that predictability is exactly what makes it useful for testing whether each step of the coding loop is working correctly.

/goal Build a playable Tower of Hanoi web game.

3. Build a chess web game

Maybe you are not impressed by the Tower of Hanoi example, since a regular prompt to any frontier model can do the same thing without a coding loop. Fair. The chess game experiment is something you should actually try for yourself.

/goal Build a playable chess web game. 
Include easy, medium, and hard difficulty levels. 
No online multiplayer needed. 
Use a Python backend as the AI engine.

4. A typing practice game for kids

/goal I want to build a typing practice web app for kids. 
At the bottom of the screen are 9 keys representing the positions of 10 fingers, with the thumbs sharing a wider spacebar key that takes up two slots. 
Above those 9 keys is a gradient-transparent rectangle. 
Letters fall down from the top toward that rectangle, aligned to their matching key positions. 
Press the right key as the letter enters the zone and it counts as a hit, triggering a hit effect. 
Consecutive correct hits build up increasingly dramatic effects. 
The falling speed gradually increases. 
At the top of the screen is a scoreboard that adds 1 point for each hit, with a pop animation. 
The whole thing should feel exciting and dopamine-triggering, with plenty of visual encouragement.

Pretty cool, right? Feeling curious?

Go ahead and check out my latest article No Plugins Needed, I Built a Fully Automated Coding Loop in OpenCode for the full tutorial, which covers:

My implementation approach.
How to use it.
The complete source code.

It's all free, so what are you waiting for?

The essence of prompt engineering isn't about feeding the model more information. It's about helping both the model and humans put their limited attention in the right place.

Peng Qian — Wed, 01 Jul 2026 06:14:54 +0000

Peng Qian

Jul 1

Why Well-Written Prompts Are Almost Always Structured

#ai #programming #productivity #tutorial

2 min read

Why Well-Written Prompts Are Almost Always Structured

Peng Qian — Wed, 01 Jul 2026 06:13:02 +0000

There's been endless debate about which language format prompts should be written in. Last year it was Markdown vs. JSON, this year it's Markdown vs. HTML.

But if you ask me, the answer has never been about the format itself. The reason why some prompts work so well all points to the same thing: structure.

The essence of prompt engineering isn't about feeding the model more information. It's about helping both the model and humans put their limited attention in the right place. Structured languages happen to do exactly that. They use just a few markers to distribute attention ahead of time within the text.

Let me give you an example. Take a look at this natural language first:

We're going on a picnic on July 1st, the destination is xx City's Second Park (Central Park). We'll drive there. You take the ring road from the south side of the city, and I'll drive straight from the north side. We'll meet at 8 AM at Entrance 2 of Second Park. Remember to bring tuna sandwiches, bottled water, and a Bluetooth speaker. I'll bring a picnic blanket, a tent, chicken sandwiches, and mosquito repellent. Also, don't forget to book the park tickets on the app in advance. You can only book one day ahead. Search for xx City's Second Park on the app.

So where are we meeting? You'd have to spend a lot of time digging through the text to find it. But if we switch to a structured description, it's a whole different story:

### Picnic Location
xx City's Second Park

### Meeting Time and Place
- July 1st, meet at 8 AM
- **Entrance 2** of Second Park

### Transportation
- You: Drive via the ring road
- Me: Drive straight from the north side

### Items to Bring
- You: **Tuna** sandwiches, bottled water, Bluetooth speaker
- Me: **Chicken** sandwiches, picnic blanket, tent, mosquito repellent

### Special Notes
- Must book tickets on the app in advance, search for *xx City's Second Park*
- **Can only book one day ahead**

See? After writing it this way, if I ask you which entrance we're meeting at, your search efficiency goes way up, right?

By categorizing and highlighting key points, the important information grabs your attention early on, instead of getting lost in a sea of text.

I wrote a full article explaining my take on structured prompts in plain language. If you're interested, feel free to click and read on.

Don't wait for a multimodal DeepSeek-v4 model, you can use my plugin now to read images.

Peng Qian — Mon, 15 Jun 2026 06:18:01 +0000

Peng Qian

Jun 15

DeepSeek-V4 Can't Read Images? I Made It Read

#ai #programming #coding #vibecoding

4 min read

DEV Community: Peng Qian

Most AI coding workflows start to drift once the context gets too long. I introduced a graph engine based on a state machine to the AIDLC workflow. This engine guides the workflow's execution, which solves the drift problem.

How I Fixed the AI Coding Workflow Drift with a Simple Script

Judgment to the model, precision to the tool, decisions to humans

What Problem I Ran Into

Why This Problem Happens

Using a Graph Engine in AIDLC

Step one: define the workflow metadata

Step two: set up multiple workflows based on scenario

Step three: turn the metadata into a workflow graph

Step four: use the script engine to run the workflow precisely

Step five: use a state file to precisely record the workflow state

Demo the Script Engine with a Small Project

Conclusion

Further Reading

I spent over a month reworking the entire team's AI Coding workflow. We brought in Amazon's aidlc-workflows and adapted it to fit our own needs. Both the team's AI development efficiency and code quality improved significantly.

From OpenSpec to AIDLC: How I Improved My Team's AI Code Quality

Introduction

What Actually Went Wrong with OpenSpec

Using it got way too complicated

It never captured the original intent

It's hard to get the right level of detail for requirements

Documentation stops matching reality

You never know when to start the process

Team collaboration falls apart

What's My Solution

What is AIDLC

What is dynamic workflow planning

What is dynamic team collaboration

How We Put AIDLC to Work on Our Team

Turning AIDLC into a Skill

Extending the AIDLC workflow

Keeping documentation consistent

Separating approval from execution

Signing off on the audit trail

Using the question tool

Testing and other best practices

Conclusion

I spent over a month reworking the entire team's AI Coding workflow. We brought in Amazon's aidlc-workflows and adapted it to fit our own needs. Both the team's AI development efficiency and code quality improved significantly.

With the same Kimi K3 quota and similar quality, you can get more done. This post outlines how I optimized my OpenCode setup to reduce Kimi K3 costs.

How I Cut Kimi K3 Costs in OpenCode

Introduction

Pick the Right Provider

Pick the Right Model and Thinking Level (Variants)

Pick the right model

Pick the thinking level

What's next?

Further Reading

The concept of Loop Engineering has been getting a lot of buzz lately, so I decided to give it a shot in OpenCode. The results were surprisingly good:

How I Built a Fully Automated Coding Loop in OpenCode

Introduction

What Andrew Ng Says About the Coding Loop

My Attempts

1. Write a Fibonacci script

2. Build a Tower of Hanoi web game

3. Build a chess web game

4. A typing practice game for kids

Pretty cool, right? Feeling curious?

Further Reading

The essence of prompt engineering isn't about feeding the model more information. It's about helping both the model and humans put their limited attention in the right place.

Why Well-Written Prompts Are Almost Always Structured

Don't wait for a multimodal DeepSeek-v4 model, you can use my plugin now to read images.