DEV Community: Peng Qian

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

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

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

Don't wait for a multimodal model, you can use it now

Introduction

Have you ever had that frustrating moment: you are coding with deepseek-v4 in OpenCode, your code throws an error, you want to screenshot it and send it to DeepSeek, and then you remember that DeepSeek cannot read images.

I have to say deepseek-v4 is cheap, easy to use, and has a long context. It has already become my main coding model. But as of mid-June, DeepSeek still hasn't released a multimodal version. That means anything involving images, like reading error screenshots, interpreting charts, or recreating pages from visual designs, it cannot do.

I am not the only one frustrated. My friends are all waiting eagerly too.

But I found a way: I developed a small plugin called observer in OpenCode that lets deepseek-v4 call a multimodal agent to gain the ability to read images indirectly.

After more than a month of polishing, this plugin now handles all image-related coding tasks in my daily work. Today, I will share how I built this plugin, hoping it can help you too.

The plugin code and agent definitions mentioned in this article are at the end. Feel free to grab them.

Demo of Real-World Results

Before diving into the long tutorial, you probably care most about how well this plugin works and whether it is worth your time to try. So let me show you some screenshots of the plugin in action.

1. Interpreting error stack traces

We start with the simplest task: have deepseek-v4 interpret a screenshot of an error stack trace and find key information. I randomly picked a screenshot of an error I encountered at work:

Then in OpenCode Desktop, I sent this image to the plan agent using deepseek-v4-pro and asked it to provide a solution:

As you can see, the plan agent gave an answer based on the screenshot information.

2. Interpreting charts

Another multimodal use case is interpreting charts from documents. For this example, I took a screenshot of a company's annual revenue chart and tested it. I still used the plan agent with deepseek-v4-pro. For an extra challenge, I asked the agent to give some key insights on the numbers in the chart:

The agent read the numbers from the chart and provided some key insights:

3. Developing HTML pages from designs

In frontend development, the biggest demand for multimodal capability is recreating visual designs. Here I found a design with complex page elements to see if the build agent using deepseek-v4-flash could recreate the page:

Here is the recreated page:

One thing is sure: the deepseek-v4-flash model generated the frontend code, and it only took one prompt to get this result. It did not get a 100% match, but with a few more rounds of conversation, you can tweak it until it is perfect. Keep in mind deepseek-v4-flash is dirt cheap.

It costs several times or even ten times less than multimodal models like kimi k2.6 or qwen3.7 plus. They are not in the same league.

Of course, you can also crop a section of the page, mark the areas that need attention, and ask DeepSeek to adjust them, like this:

The agent perceives the marked area and gives the primary agent an adjustment plan per your request.

4. Generating HTML pages from hand-drawn sketches

Maybe you are like me and have zero design skills. No problem. We can hand-draw rough sketches. The agent can understand them. For example, in a recent project, I hand-drew a few web page design sketches:

Then deepseek-v4-flash helped me recreate the page:

Impressive, right?

Detailed Implementation Walkthrough

Next, you'll find out:

How I designed this plugin and agent.
Why I designed it that way.

Click on my full article to keep reading.

Your AI always writes messy code? That's because your spec files have never been properly reviewed. By adding a reflection mechanism to the proposal stage of OpenSpec, I got DeepSeek-v4-pro to match Opus 4.6 in coding ability:

Peng Qian — Mon, 01 Jun 2026 04:05:05 +0000

Peng Qian

Jun 1

Reflection SDD: Use a Reflection Harness to Level Up Your OpenSpec Workflow

#ai #programming #coding #vibecoding

9 min read

DEV Community: Peng Qian

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

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.

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

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

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

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

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.

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

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

Introduction

Demo of Real-World Results

1. Interpreting error stack traces

2. Interpreting charts

3. Developing HTML pages from designs

4. Generating HTML pages from hand-drawn sketches

Detailed Implementation Walkthrough

Further Reading

Your AI always writes messy code? That's because your spec files have never been properly reviewed. By adding a reflection mechanism to the proposal stage of OpenSpec, I got DeepSeek-v4-pro to match Opus 4.6 in coding ability:

Reflection SDD: Use a Reflection Harness to Level Up Your OpenSpec Workflow