Raise the bar. Fix everything.

The next era of
software engineering.

AI gives us the tools to build substantially better software. Use that capacity with human judgment, thoughtful design and the highest standards for what we ship.

Written by
Andrius Bartulis

Andrius Bartulis

I wrote this to help teams make better use of agents: explore more options, make thoughtful decisions, and build software worthy of users’ trust.

How the work gets done.

DESIGN → BUILD → REFINE → OPERATE
01DESIGN

Product &
technical design

Goals · User journeys · Quality bar
Architecture · Data · APIs

02BUILD

Build
and review

Guide the implementation.
Separate agents test and challenge it.

03REFINE

Try it.
Refine the design.

Try the experience. Inspect the evidence.
Refine it together.

04OPERATE

Monitoring
and recovery

Learn from real use.
Monitor, challenge and improve.

How should we build software in the age of AI?

AI gives us the tools to build substantially better software. Use that capacity to raise our standards.

Extra reading: dark factories and the limits of automation

Raise the quality bar.

Use AI to build substantially better software. Expect more from what you ship.

Agents make it practical to explore more alternatives, challenge more assumptions and test more thoroughly. Use the time you gain to improve the design, refine the experience and investigate weaknesses you would once have left unexplored.

Quality remains a moat.

Generating code is easy. Creating a product people trust takes judgment, thoughtful design and evidence that it works. Quality remains a moat alongside reputation, service and customer relationships. Generating code blindly will not get you there.

Aim for the highest quality bar. Make it concrete: usefulness, usability, accessibility, reliability, performance, security and maintainability. Care about the details people encounter every day and the foundations that let you keep improving them.

Judge the work by the value it delivers, the experience it gives users and how well it holds up over time.

Own the product and the decisions.

Work with agents throughout. Bring your judgment, taste and responsibility to every stage.

Define the problem, explore the design and guide the implementation as you learn. Stay close to the working product. Deciding what deserves to ship remains a human responsibility.

Humans own
Product goals and the quality bar, architecture, API contracts, data models, authentication boundaries, performance budgets and consequential decisions.
Agents help
Explore alternatives, implement and integrate changes, write documentation and tests, and challenge the design through architecture and security reviews.

The working loop

  1. Define the product.

    Agree on who it serves, the problem to solve, the smallest useful journey and the standards it must meet.

  2. Design the system.

    Work out the technical design with agents. Compare approaches, challenge assumptions and record the trade-offs.

  3. Build with agents.

    Have agents deliver a complete, working slice, including integration and tests. Guide decisions as they arise and have separate agents challenge the result.

  4. Review the working product.

    Try the real user journey. Assess usability, accessibility and the care in the details. Inspect evidence against the product and technical standards.

  5. Refine the design and repeat.

    Use what you learn to improve the product and technical design. Work with agents to implement and recheck each revision.

You remain accountable for the quality of what reaches users.

Demand evidence.

Make every release earn your confidence through real use, independent checks and measured results.

The agent that built a feature can miss the same mistake when it writes the tests. Have other agents check behaviour against the requirements, review architecture and audit security.

Use separate review contexts so agents don’t simply inherit the builder’s assumptions. They can still share blind spots. Check their findings against real behaviour, explicit standards and human judgment.

Put human attention where judgment matters.

Keep PRs as a record of the change, decisions and checks. Make the evidence clear enough for reviewers to understand what changed, what was verified and what remains uncertain.

Teams can agree to let routine, reversible changes proceed within defined authority when they fit the agreed design and pass credible checks. The team owns those rules and remains accountable for the result. Any developer can request a human review.

Route changes to the agreed architecture or technical design, unusually complex work and changes with serious consequences to the right person. Explain the risks and the decision that needs their judgment. Escalate uncertainty too.

When a defect escapes, improve the design or add a check that would have caught it.

Shorten the path to excellent software.

Remove waiting, rework and repetitive tasks. Spend the capacity you gain on better decisions and a better product.

Track time from idea to a useful result, including waits for decisions, environments, reviews and rework. Fix the largest constraint, then measure again. Limit work in progress so unfinished tasks don’t pile up.

Borrow the focus on flow from Toyota’s production system and the attention to constraints from The Goal.

Make the work reproducible.

Give each task a reproducible environment and only the access it needs. Cloud workspaces can let agents build and check changes in parallel. Choose the tools that help the team do excellent work.

Use system maps, data models, performance traces and review reports to assess the design. Read the code whenever it helps you resolve uncertainty or make a consequential decision.

Keep improving after release.

Learn from real use. Keep challenging the system and refining the experience.

Watch where users struggle, listen to feedback and revisit assumptions. Use agents to investigate friction, explore improvements and verify changes. Product quality includes how well the experience serves people over time.

Keep trying to break it.

Have agents continually challenge staging: explore user journeys, fuzz inputs, test permissions, interrupt dependencies and probe performance limits. Use isolated test data and cap resource use.

Keep watching after deployment.

Agents should watch deployments, logs, errors and latency, trace regressions to changes, and propose fixes. Test those fixes in staging and check that recovery worked.

Agents can act
Let agents handle known repairs within agreed permissions, using the same release checks as new features.
Humans decide
Own product priorities and consequential trade-offs. Bring uncertain root causes, design changes, sensitive data decisions and actions beyond agreed authority to a human.

Track user outcomes, escaped defects, performance and the ease of maintaining the system. Use what you learn to improve it.

Dark factories and the limits of automation.

Automate the work. Keep human judgment involved.

A software factory can satisfy a specification and still miss what makes a product useful.

StrongDM’s approach uses specifications and external scenarios to guide agents. One rule is Code must not be reviewed by humans. Human judgment still defines what success means.

Checks leave gaps.

An export can contain the right data and still frustrate users. D’Amour et al. found that ML predictors with similar test performance can behave very differently in deployment domains. Their study concerns ML pipelines; my takeaway is to assess what passing checks leave unresolved.

D’Amour et al., Underspecification Presents Challenges for Credibility in Modern Machine Learning. JMLR, 2022.

AI review has biases.

Zheng et al. identified position, verbosity, and self-enhancement biases in chatbot judges, despite more than 80% agreement with human preferences. AI review provides useful evidence. Assessing a complete product also calls for real use and explicit standards.

Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS, 2023.

Scores can reward shortcuts.

MacDiarmid et al. gave an experimental model knowledge of reward hacks and trained it in coding environments. It learned to cheat and developed harmful behaviours. After chat-based safety training, misalignment persists on agentic tasks. This shows a failure mode, not inevitable cheating by coding agents.

MacDiarmid et al., Natural Emergent Misalignment from Reward Hacking in Production RL. Research preprint, 2025.

These findings warrant scrutiny; they do not prove that every factory must fail. My position: keep humans responsible for product goals, consequential trade-offs and release decisions.

Try the product. Listen to users. Refine the design. Keep someone responsible for deciding what deserves to ship.

START HERE / ONE REAL SYSTEM

Make one user journey excellent.

Choose one troublesome user journey. Set the quality bar, explore the design with agents and build a complete slice. Try it with the people it serves, inspect the evidence and refine it until it meets your standards. Track user outcomes, escaped defects and delivery time.

Explore the delivery simulator

We can fix everything. And we will.