But do we need to prompt and manage agents separately for every one of these tasks?
What if we designed the entire software development lifecycle (SDLC) as an automated workflow?
This is where the concept of an AI software factory becomes important.
Put simply, a software factory connects different steps of the development process through AI agents, automated tools and human oversight, creating a repeatable workflow.
For example:
Issue → Triage → Spec → Implement → Review → Verify → Deploy → Monitor
A triage agent analyzes the task. If needed, a specification agent clarifies the requirements. An implementation agent writes the code. Review and verification agents check the results.
The workflow can request human approval for risky changes. After deployment, issues found through monitoring can feed back into the workflow.
In an earlier article, we discussed AI harness engineering.
An AI harness supplies the environment, tools, context and execution controls an agent needs to operate.
A software factory orchestrates the development workflow from planning through deployment and monitoring. It may use one or several harnesses to do this.
We can think about two ways of running a software factory, depending on its level of automation.
Not every project is suitable for a fully dark factory.
The concepts of one-way and two-way doors, and blast radius from the previous article can help us automate more low-risk changes while retaining human approval for high-risk changes.
For that reason, a hybrid approach is often more practical.
It helps to think in terms of two loops:
We continuously improve both the software and the system that creates it. Changes to that system should undergo validation and appropriate human oversight.
Our goal is to deliver more valuable software while maintaining quality and optimizing human time, token cost, review time and rework, rather than simply generating more code or pull requests.
That requires measuring the factory’s performance, identifying weaknesses and improving its workflows.
This is the key shift in the software factory mindset:
We build software, and we engineer the system that builds the software.
How much of your project’s development workflow do you think could be automated with AI agents? Share your thoughts in a comment.
If this article was useful, share it with a friend. We will explore another technical topic in the next article.
]]>නමුත් මේ හැම Task එකකටම අපි වෙන වෙනම Prompts ලබාදීලා Agents Manage කරන්න ඕනද?
ඒ වෙනුවට සම්පූර්ණ Software Development Lifecycle (SDLC) එක Automated Workflow එකක් විදිහට සැලසුම් කළොත්?
මෙතැනදී තමයි AI Software Factory කියන සංකල්පය වැදගත් වෙන්නේ.
සරලව කිව්වොත්, Software Development Process එකේ විවිධ පියවර AI Agents, Automated Tools සහ Human Oversight එකට සම්බන්ධ කරලා, නැවත නැවත භාවිත කළ හැකි Workflow එකක් නිර්මාණය කිරීමයි.
උදාහරණයක් විදිහට:
Issue → Triage → Spec → Implement → Review → Verify → Deploy → Monitor
මෙහිදී Triage Agent එකක් Task එක විශ්ලේෂණය කරනවා. අවශ්ය නම් Spec Agent එකක් Requirements පැහැදිලි කරනවා. Implementation Agent එක Code ලියනවා. Review සහ Verification Agents ප්රතිඵල පරීක්ෂා කරනවා.
අවදානම් සහිත අවස්ථාවල Human Approval ලබාගන්නත්, Deploy කළාට පස්සේ Monitoring හරහා හඳුනාගන්නා Issues නැවත Workflow එකට යොමු කරන්නත් පුළුවන්.
කලින් Post එකක අපි AI Harness Engineering ගැන කතා කළා.
AI Harness එකකින් Agent එකක් ක්රියාත්මක වීමට අවශ්ය Environment, Tools, Context සහ Execution Controls සපයනවා.
Software Factory එකකින් Planning සිට Deployment සහ Monitoring දක්වා Development Workflow එක Orchestrate කරනවා. ඒ සඳහා Harness එකක් හෝ කිහිපයක් භාවිත කරන්න පුළුවන්.
Automation මට්ටම අනුව Software Factories ක්රියාත්මක කරන ආකාර දෙකක් ගැන හිතන්න පුළුවන්.
නමුත් හැම Project එකක්ම සම්පූර්ණ Dark Factory එකක් බවට පත් කරන්න සුදුසු නැහැ.
කලින් Post එකේ කතා කළ One-Way / Two-Way Door සහ Blast Radius වගේ සංකල්ප භාවිත කරලා, Low-Risk Changes වැඩි වශයෙන් Automate කරන්නත්, High-Risk Changes සඳහා Human Approval පවත්වාගන්නත් පුළුවන්.
ඒ නිසා බොහෝ අවස්ථාවල Hybrid Approach එකක් වඩාත් ප්‍රායෝගිකයි.
මෙහිදී Loops දෙකක් ගැන හිතන්න පුළුවන්.
ඒ කියන්නේ අපි Software එක විතරක් නොවෙයි, Software නිර්මාණය කරන පද්ධතියත් අඛණ්ඩව වැඩිදියුණු කරනවා. මෙවැනි වෙනස්කම් Validation සහ සුදුසු Human Oversight යටතේ සිදු විය යුතුයි.
අපේ අරමුණ වැඩි Code හෝ PRs ප්රමාණයක් Generate කිරීම විතරක් නෙවෙයි. Software Quality පවත්වාගෙන යමින්, Human Time, Token Cost, Review Time සහ Rework Optimize කරලා වැඩි වටිනාකමක් ඇති Software Deliver කිරීමයි.
ඒ සඳහා Factory එකේ Performance මැනීමත්, අඩුපාඩු හඳුනාගෙන Workflows වැඩිදියුණු කිරීමත් වැදගත්.
Software Factory Mindset එකේ වැදගත්ම වෙනස මෙයයි.
අපි Software එක නිර්මාණය කරනවා විතරක් නෙවෙයි. Software එක නිර්මාණය කරන පද්ධතියත් Engineer කරනවා.
ඔබේ Project එකේ Software Development Workflow එකෙන් කොපමණ ප්රමාණයක් AI Agents භාවිතයෙන් Automate කරන්න පුළුවන් කියලා හිතනවද? ඔබේ අදහස් Comment එකකින් බෙදාගන්න.
මේ Post එක වැදගත් වුණා නම් ඔබේ මිතුරන් එක්කත් Share කරන්න. තවත් රසවත් තාක්ෂණික මාතෘකාවකින් ඊළඟ Post එකෙන් හමුවෙමු!
]]>But does the speed of reviewing that code and getting it into production increase just as much?
This is where the concept of review tax matters.
As AI-generated PRs multiply, reviewing, validating and correcting them can take more time. Code generation becomes faster, while the overall development process may become slower.
No. A few concepts help us decide how much review a change needs.
How much of the system could the PR affect? Changing a small UI component and changing the authentication system do not carry the same risk.
An agent saying “tests pass” is not enough. Real evidence, such as test results, screenshots and before/after behavior, matters.
For PRs that are low risk, have a small blast radius and are easy to reverse, AI code review, automated tests and CI checks can support reduced human review or auto-merge, within appropriate safeguards.
Changes that are high risk, have a large blast radius or are difficult to reverse need greater attention and human approval.
AI can also help assess risk. Controls that validate those assessments remain important.
Our goal is to maintain software quality, allocate review effort according to risk, and move changes safely into production.
Give the most engineering attention to the PRs with the greatest risk, instead of spending the same review time on every PR.
Does your team have a dedicated process for reviewing AI-generated PRs? Share your thoughts.
In the next article, we will discuss the concept of an AI software factory.
]]>නමුත් Code ලියන වේගය වැඩි වුණාට, ඒ Code එක Review කරලා Production එකට යොමු කරන වේගයත් ඒ තරමටම වැඩි වෙනවද?
මෙතැනදී තමයි Review Tax කියන සංකල්පය වැදගත් වෙන්නේ.
AI-generated PRs වැඩි වෙනකොට ඒවා Review කරන්න, Validate කරන්න සහ නැවත නිවැරදි කරන්න වැඩි කාලයක් වැය වෙන්න පුළුවන්. අවසානයේ Code Generation වේගවත් වුණත් සමස්ත Development Process එක මන්දගාමී වෙන්න පුළුවන්.
නැහැ! මෙතැනදී වැදගත් සංකල්ප කිහිපයක් තියෙනවා.
PR එකකින් System එකේ කොපමණ කොටසකට බලපෑමක් ඇති වෙන්න පුළුවන්ද? කුඩා UI Component එකක් වෙනස් කිරීම සහ Authentication System එක වෙනස් කිරීම අතර අවදානම එකම මට්ටමේ නැහැ.
AI Agent එක “Tests Pass” කියලා පැවසීම විතරක් ප්රමාණවත් නැහැ. Test Results, Screenshots සහ Before/After Behavior වගේ සැබෑ Evidence ලබාදීමත් වැදගත්.
Low Risk + Small Blast Radius + Easily Reversible PRs සඳහා AI Code Review, Automated Tests සහ CI Checks භාවිත කරලා, සුදුසු ආරක්ෂක සීමාවන් යටතේ Human Review අඩු කරන්න හෝ Auto-Merge කරන්න පුළුවන්.
නමුත් High Risk, Large Blast Radius හෝ Difficult-to-Reverse වෙනස්කම් සඳහා වැඩි අවධානයක් සහ Human Approval අවශ්යයි.
මේ Risk Assessment එකත් AI මඟින් සිදු කරන්න පුළුවන්. නමුත් ඒ තීරණ Validate කරන Controls තිබීම වැදගත්.
AI යුගයේ අපේ අරමුණ වැඩි PR ප්රමාණයක් Generate කිරීම විතරක් නෙවෙයි. Software Quality පවත්වාගෙන යමින්, අවදානම අනුව Review Effort එක වෙන් කරලා, Changes ආරක්ෂිතව Production එකට යොමු කිරීමයි.
හැම PR එකකටම සමාන Review Time එකක් වැය කරනවා වෙනුවට, වැඩිම අවදානමක් තියෙන PR වලට වැඩිම Engineering Attention එක ලබාදීමයි වැදගත්.
ඔබේ Team එකේ AI-generated PRs Review කරන්න වෙනම Process එකක් තියෙනවද? ඔබේ අදහස් Comment එකකින් බෙදාගන්න.
මීළඟ Post එකෙන් AI Software Factory කියන සංකල්පය කතා කරමු!
]]>This cycle of repeatedly circling the same problem is called a doom loop.
One major cause is poor context.
Suppose our project’s architecture has changed, but the agent is still using old documentation. Even if it writes good code, the implementation may not match the actual requirements.
Wrong context → Wrong implementation → Re-prompting → Rework → Higher token use and development cost.
Not necessarily.
Connecting every document, data source and MCP server in a project does not guarantee better results.
As the amount of information grows, identifying the right information can become harder, especially when sources are outdated, irrelevant or contradictory.
Having access to information and identifying the right information are two different things.
This is where context engineering and the idea of a context engine become useful.
We should focus on:
Adding AGENTS.md, rules files or MCP servers can help. The information they provide must also be accurate, relevant and trustworthy.
We need to engineer a way to provide the right context, at the right time, in the right amount.
This can reduce doom loops and unnecessary rework, optimize token use and development cost, and improve software quality and development efficiency.
The model’s capabilities matter. To use those capabilities effectively, the quality of the context it receives matters just as much.
Have you experienced a doom loop while working with AI coding agents? Share your experience.
In the next article, we will discuss code reviews and the “review tax” in the agentic AI era.
]]>මේ විදිහට එකම ගැටලුව වටා නැවත නැවත යන තත්ත්වය Doom Loop ලෙස හඳුන්වනවා.
මෙයට බලපාන ප්රධාන හේතුවක් තමයි Poor Context.
හිතන්න අපේ Project එකේ Architecture එක වෙනස් වෙලා. නමුත් AI Agent එක තවමත් පරණ Documentation භාවිත කරනවා කියලා. එතකොට Agent එක හොඳ Code එකක් ලිව්වත්, ඒක සැබෑ Requirements වලට ගැළපෙන්නේ නැති වෙන්න පුළුවන්.
වැරදි Context → වැරදි Implementation → Re-prompting → Rework → වැඩි Token Usage සහ Development Cost.
අනිවාර්යයෙන්ම නැහැ!
අපේ Project එකේ තියෙන හැම Documentation එකක්ම, Data Source එකක්ම සහ MCP Server එකක්ම Agent එකට සම්බන්ධ කළා කියලා ප්රතිඵල වඩා හොඳ වෙනවා කියලා සහතික කරන්න බැහැ.
තොරතුරු ප්රමාණය වැඩි වෙනකොට Agent එකට නිවැරදි තොරතුරු හඳුනාගැනීම අපහසු වෙන්න පුළුවන්. විශේෂයෙන් පරණ, අදාළ නොවන හෝ එකිනෙකට පටහැනි තොරතුරු තියෙන විට.
Information Access තිබීම සහ නිවැරදි Information එක හඳුනාගැනීම කියන්නේ වෙනස් දේවල් දෙකක්.
මෙතැනදී තමයි Context Engineering සහ Context Engine සංකල්ප වැදගත් වෙන්නේ.
අපි අවධානය දෙන්න ඕන:
AGENTS.md, Rules Files හෝ MCP Servers එකතු කිරීම ප්රයෝජනවත් වුණත්, ඒවා හරහා ලැබෙන තොරතුරු නිවැරදිද, අදාළද සහ විශ්වාසදායකද කියන එකත් වැදගත්.
AI Agent එකට හැකි තරම් Context ලබාදීම වෙනුවට, නිවැරදි Context එක අවශ්ය වෙලාවට, අවශ්ය ප්රමාණයෙන් ලබාදෙන ක්රමවේදයක් Engineer කිරීමයි වැදගත්.
ඒ හරහා Doom Loops සහ අනවශ්ය Rework අඩු කරලා, Token Usage සහ Development Cost Optimize කරමින් Software Quality සහ Development Efficiency වැඩිදියුණු කරන්න පුළුවන්.
AI Model එකේ හැකියාවන් වැදගත්. නමුත් ඒ හැකියාවන් නිවැරදිව භාවිත වෙන්න නම්, Model එකට ලැබෙන Context එකේ Quality එකත් ඒ තරමටම වැදගත්.
ඔබත් AI Coding Agents භාවිත කරද්දී මේ වගේ Doom Loops වලට මුහුණ දීලා තියෙනවද? ඔබේ අත්දැකීම් Comment එකකින් බෙදාගන්න.
මීළඟ Post එකෙන් Agentic AI යුගයේ Code Reviews සහ “Review Tax” ගැන කතා කරමු!
]]>This is where AI harness engineering becomes important.
When we use an LLM on its own, it usually returns a response to our input. An agentic task involves more than a single response.
Suppose we ask AI: “Add a feature to this project and check that it works correctly.”
The AI needs to read files, change code, run tests, identify errors and fix them.
It might use an execution loop such as Read → Plan → Act → Observe → Evaluate → Repeat. Not every agentic workflow needs to follow exactly that sequence.
It is useful to distinguish the agent from its harness:
| AI agent | A system that decides what to do next to achieve a goal and uses the necessary tools. |
| AI harness | The software infrastructure that supplies the agent’s execution environment, tools, context and controls, and manages its execution loop or workflow. |
Put simply, the agent decides what to do next. The harness provides the facilities to carry out those decisions and control the process. In practice, some frameworks combine these responsibilities.
The harness also manages the process until the task is complete, a defined limit is reached or human intervention is needed.
It may include capabilities for context, memory, tools, security, permissions and evaluation.
The harnesses used by coding agents such as Claude Code and OpenAI Codex are examples.
Yes. We can customize an existing harness, such as Codex or Claude Code, to fit a project.
For example:
Much of this can be done without changing the harness’s source code.
Imagine building a specialized AI agent for a banking application.
It may need strict security policies, local LLM use, language validation, sensitive data protection, audit logs, observability, compliance checks and human approval.
For such a use case, we could customize an existing harness or build a domain-specific harness using frameworks such as Google ADK or LangGraph.
The right approach depends on the requirements of the use case.
We should pay attention to engineering the harness to fit the project, alongside writing prompts.
For example, we can add UI testing through Playwright, application-log access, project context through MCP and automated feedback loops.
Designing these well can reduce unnecessary iterations, optimize token use and development cost, and improve software quality and development efficiency.
Our goal is to maintain software quality while making the development process more efficient. The environment in which AI works needs careful engineering too. That is why harness engineering matters.
If this article was useful, share it with a friend. Share your thoughts and experiences with harness engineering as well.
We will explore another technical topic in the next article.
]]>මෙතැනදී තමයි AI Harness Engineering වැදගත් වෙන්නේ.
LLM එකක් තනිව භාවිත කරන විට සාමාන්යයෙන් අපේ Input එකට Response එකක් ලබාදෙනවා. නමුත් Agentic Task එකකදී ඒ Response එකෙන් පමණක් නවතින්නේ නැහැ.
හිතන්න අපි AI එකට කියනවා, “මේ Project එකට Feature එකක් එකතු කරලා, ඒක නිවැරදිව වැඩ කරනවද පරීක්ෂා කරන්න” කියලා.
මෙතැනදී AI එකට Files කියවන්න, Code වෙනස් කරන්න, Tests Run කරන්න, Errors හඳුනාගෙන නැවත නිවැරදි කරන්න සිදුවෙනවා.
ඒ සඳහා Read → Plan → Act → Observe → Evaluate → Repeat වගේ Execution Loop එකක් භාවිත කරන්න පුළුවන්. හැබැයි හැම Agentic Workflow එකක්ම මේ ආකාරයට ක්රියාත්මක වෙන්න අවශ්ය නැහැ.
මෙතැනදී AI Agent එක සහ Harness එක අතර වෙනසත් තේරුම් ගන්න ඕන.
| AI Agent | Goal එකක් ඉටු කරන්න ඊළඟට කළ යුතු දේ තීරණය කරමින් අවශ්ය Tools භාවිත කරන පද්ධතිය. |
| AI Harness | Agent එකට අවශ්ය Execution Environment, Tools, Context සහ Controls සපයමින් එහි Execution Loop එක හෝ Workflow එක කළමනාකරණය කරන Software Infrastructure එක. |
සරලව කිව්වොත් Agent එක ඊළඟට කළ යුතු දේ තීරණය කරන අතර Harness එක ඒ තීරණ ක්රියාත්මක කිරීමට සහ ක්රියාවලිය පාලනය කිරීමට අවශ්ය පහසුකම් සපයනවා. ප්රායෝගිකව මේ වගකීම් සමහර Frameworks වල එකිනෙකට සම්බන්ධ වෙන්නත් පුළුවන්.
Task එක සම්පූර්ණ වෙනතුරු, නියමිත සීමාවකට ළඟාවෙනතුරු හෝ Human Intervention අවශ්ය වෙනතුරු ක්රියාවලිය පාලනය කිරීමත් Harness එකේ කාර්යයක්.
ඒ වගේම Context, Memory, Tools, Security, Permissions සහ Evaluation වගේ හැකියාවනුත් Harness එකට ඇතුළත් වෙන්න පුළුවන්.
Claude Code, OpenAI Codex වගේ Coding Agents වල Harness මේ සඳහා උදාහරණ.
ඔව්! Codex, Claude Code වගේ දැනට තියෙන Harness එකක් අපේ Project එකට ගැළපෙන විදිහට Customize කරන්න පුළුවන්.
උදාහරණයක් විදිහට:
මේ බොහෝ දේවල් කරන්න Harness එකේ Source Code වෙනස් කරන්න අවශ්ය නැහැ.
හිතන්න අපි Banking Application එකක් සඳහා විශේෂ AI Agent එකක් නිර්මාණය කරනවා කියලා.
එතැනදී දැඩි Security Policies, Local LLM Usage, Language Validation, Sensitive Data Protection, Audit Logs, Observability, Compliance Checks සහ Human Approval වගේ විශේෂ අවශ්යතා තිබෙන්න පුළුවන්.
මෙවැනි අවස්ථාවක Claude Code, Codex වගේ Existing Harness එකක් Customize කරන්න හෝ Google ADK, LangGraph වගේ Frameworks භාවිතයෙන් අපේම Domain-Specific Harness එකක් නිර්මාණය කරන්න පුළුවන්.
සුදුසු ක්රමය තීරණය වෙන්නේ අපේ Use Case එකේ අවශ්යතා අනුවයි.
AI එකට Prompts ලබාදෙන එකෙන් විතරක් නවතින්නේ නැතුව, අපේ Project එකට ගැළපෙන විදිහට Harness එක Engineer කිරීම ගැනත් අවධානය දෙන්න ඕන.
උදාහරණයක් විදිහට Playwright හරහා UI Testing, Application Logs කියවීම, MCP හරහා Project Context ලබාදීම සහ Automated Feedback Loops එකතු කරන්න පුළුවන්.
මේවා නිවැරදිව සැලසුම් කිරීමෙන් අනවශ්ය Iterations අඩු කරලා, Token Usage සහ Development Cost Optimize කිරීමටත්, Software Quality සහ Development Efficiency වැඩිදියුණු කිරීමටත් පුළුවන්.
අවසානයේ අපේ අරමුණ AI එකෙන් Software Develop කරගැනීම විතරක් නෙවෙයි. ඒ Software එකේ Quality එක පවත්වාගෙන යමින් Development Process එක කාර්යක්ෂම කිරීමයි. ඒ සඳහා AI එක වැඩ කරන පරිසරයත් නිවැරදිව Engineer කළ යුතුයි. Harness Engineering වැදගත් වෙන්නේ ඒ නිසයි.
මේ Post එක ඔබට වැදගත් වුණා නම්, ඔබේ මිතුරන් එක්කත් Share කරන්න. Harness Engineering ගැන ඔබේ අදහස් සහ අත්දැකීම් Comment එකකින් බෙදාගන්න.
තවත් රසවත් තාක්ෂණික මාතෘකාවකින් ඊළඟ Post එකෙන් හමුවෙමු!
]]>With AI, we can now build software for a specific need in a few hours. Sometimes we may use it for a single task or a single day, then throw it away.
Examples include a personal automation script, a one-time data analysis tool or an application for a small event.
Does that software need the same engineering effort as a banking system that will be maintained for years?
There are four main factors to consider:
If all four are very low, we can treat it as disposable software. In those cases, meeting the immediate need quickly may matter more than adding engineering complexity.
For durable software, where failure can cause serious harm, many people depend on it, and it must be maintained for years, code quality and architecture become more important.
This is not a binary distinction. The degree to which software is disposable should guide the engineering rigor we apply. And calling software disposable never means we can ignore security or safety.
The important skill in the AI era is deciding how much engineering effort each piece of software needs.
When we develop software with AI agents, AI harnesses and harness engineering also play an important role in maintaining code quality. We will explore that in the next article.
]]>AI නිසා දැන් අපිට පැය කිහිපයකින් අවශ්යතාවයකට ගැළපෙන Software එකක් හදාගන්න පුළුවන්. සමහර විට ඒක එක දවසකට, එක වැඩකට විතරක් භාවිත කරලා ඉවත් කරන්නත් පුළුවන්.
උදාහරණයක් විදිහට Personal Automation Script එකක්, One-time Data Analysis Tool එකක් හෝ කුඩා Event එකකට හදන Application එකක්.
මේ වගේ Software එකකට අවුරුදු ගණනක් පවත්වාගෙන යන Banking System එකකට දෙන Engineering Effort එකම යොදවන්න අවශ්යද?
මෙතැනදී අපි සලකා බලන්න ඕන ප්රධාන කරුණු හතරක් තියෙනවා.
මේ හතරම ඉතා අඩු නම්, ඒක Disposable Software එකක් විදිහට සලකන්න පුළුවන්. එවැනි අවස්ථාවලදී අධික Engineering Complexity එකක් එකතු කරනවාට වඩා ඉක්මනින් අවශ්යතාව ඉටු කිරීම වැදගත් වෙන්න පුළුවන්.
හැබැයි Failure එකකින් ලොකු හානියක් වෙන, බොහෝ දෙනෙක් භාවිත කරන, දිගුකාලීනව පවත්වාගෙන යා යුතු Durable Software වලදී Code Quality සහ Architecture තවත් වැදගත් වෙනවා.
මෙය කළු-සුදු බෙදීමක් නෙවෙයි. Software එකක Disposability එක අනුව යොදවන Engineering Rigor එක තීරණය කරන්න ඕන. ඒ වගේම Disposable කියලා Security හෝ Safety නොසලකා හරින්නත් බැහැ.
AI යුගයේ වැදගත්ම දේ හැම Software එකක්ම Perfect විදිහට Design කිරීම නෙවෙයි. කොයි Software එකට කොපමණ Engineering Effort එකක් අවශ්යද කියලා නිවැරදිව තීරණය කිරීමයි.
ඒ වගේම AI Agents යොදාගෙන Software Develop කරන විට Code Quality එක පවත්වාගෙන යන්න AI Harness සහ Harness Engineering ඉතා වැදගත් වෙනවා. ඒ ගැන ඊළඟ Post එකෙන් කතා කරමු!
]]>