How We Use AI at Microcorem: Leverage Without Abdicating Responsibility

AI can dramatically accelerate software development

The most immediate benefit of AI-assisted development is speed.

A capable engineer can use an AI coding assistant to move quickly through work that is necessary but often time-consuming: generating an initial implementation, writing repetitive integration code, creating test cases, exploring an unfamiliar API, tracing an error through a codebase or comparing several possible approaches.

This does not remove the need to understand the code. It changes where engineering time is spent.

Consider an engineer joining an existing project. Traditionally, a substantial part of the first few days might be spent searching through the repository, following dependencies, locating configuration and reconstructing how different components interact.

AI can accelerate much of that investigation. It can explain unfamiliar modules, locate related functionality, identify likely call paths and suggest where a change needs to be made.

The engineer can then spend more time on the questions that require judgement:

• Is this behaviour intentional?
• Does the proposed change fit the existing architecture?
• What other workflows might it affect?
• Is the abstraction appropriate?
• What happens when the system evolves?

The same principle applies during implementation.

AI is particularly effective when the problem is well constrained. If the surrounding architecture and expected behaviour are clear, it can often produce a useful first implementation very quickly. The engineer can iterate on that implementation rather than starting from an empty file.

That shortening of the implementation-feedback loop can be extremely valuable.

But acceleration is not the same thing as automation. Someone still needs to determine whether the generated solution is the right solution.

AI is also a powerful analytical tool

Code generation receives much of the attention, but some of the most useful applications of AI are analytical.

Large software systems contain patterns spread across many files, services, configuration layers and documentation sources. Humans are good at understanding systems deeply, but examining all of that material takes time.

AI can provide breadth.

For example, we can ask a model to inspect a codebase and look for inconsistent error handling, duplicated validation logic, suspicious authorization patterns, missing test coverage or architectural dependencies that appear to cross intended boundaries.

Similarly, an AI-assisted review can provide a useful first pass over infrastructure configuration, API design, database access patterns or software documentation.

This makes AI particularly useful for initial audits.

An initial audit does not need to provide the final answer. Its purpose is often to map the territory.

It can identify areas worth investigating, group similar issues, discover recurring patterns and highlight anomalies. An experienced engineer can then concentrate on the places where human attention is most valuable.

This combination can be much more effective than either side working alone.

The machine provides breadth and speed. The human provides context, prioritisation and judgement.

Seeing the pieces is not the same as owning the whole

The limitations become more important as the scope of the problem expands.

Large language models are remarkably capable when solving a problem that has been placed directly in front of them. They can reason about an implementation, analyse a component, propose a refactoring or compare architectural alternatives.

What is much harder is maintaining the complete, evolving picture of a product.

That picture often contains information that is only partly written down.

An architect might know that two similar components deliberately use different implementations because their future requirements are expected to diverge.

A product owner might know that an awkward workflow exists because a particular group of customers depends on it.

An engineer might understand that a technically imperfect interface is being retained temporarily because another service will be retired in six months.

None of these decisions necessarily appears in the code immediately surrounding the task.

This creates an important distinction between local correctness and global suitability.

An AI system might correctly identify duplicated code and recommend consolidating it. From a purely local perspective, that can be excellent advice.

But if the two workflows are about to evolve in different directions, the abstraction could make future development harder.

Likewise, a model might recommend splitting a system into additional services because the separation appears architecturally clean. A human architect may recognise that the operational cost of another distributed component outweighs the theoretical benefit.

Or an AI coding agent may implement a ticket exactly as specified while missing the fact that the ticket itself is based on an outdated understanding of what users need.

These are not simply examples of AI making factual mistakes.

They are examples of a deeper problem: engineering decisions exist within a web of product goals, historical decisions, organisational constraints and future expectations.

Maintaining that picture is part of engineering leadership.

Architecture is a continuous act of judgement

Architecture is sometimes presented as something that happens before implementation: draw the system, choose the technologies and then build it.

Real systems rarely work like that.

Architecture evolves continuously.

Every new feature creates small architectural decisions. Every integration changes the dependency structure. Every workaround creates a possibility that it becomes permanent. Every new abstraction affects what becomes easy or difficult later.

AI can help with all of these decisions.

It can identify coupling. It can suggest design patterns. It can compare implementation options. It can challenge assumptions. It can help an architect think through consequences.

What it should not do is silently inherit responsibility for the architecture.

Someone still needs to ask whether the system as a whole remains coherent.

The same is true of product development.

It is relatively easy to ask AI to produce more functionality. It is much harder to determine whether that functionality should exist.

Faster development can even make this distinction more important. When the cost of generating software falls, the cost of generating the wrong software falls as well.

The scarce resource increasingly becomes judgement.

Our model: AI proposes, humans remain accountable

For us, the useful boundary is not between tasks that are performed by humans and tasks that are performed by machines.

That boundary is already becoming difficult to draw.

A single piece of software might involve an engineer defining the architecture, an AI assistant generating an implementation, the engineer changing part of it, another model generating tests, an automated system running those tests and a human performing the final review.

Trying to assign authorship line by line is not particularly useful.

A more meaningful question is:

Who is responsible for the outcome?

At Microcorem, that remains a human.

AI can investigate, generate, analyse, critique and propose. It can give us alternatives we might not have considered. It can act as a fast second pair of eyes.

But an engineer must decide whether an implementation belongs in the system.

An architect must decide whether the architecture still makes sense.

And someone must ultimately sign off that what we deliver is suitable for its intended purpose.

Human review therefore isn't a ceremonial final step added to an otherwise autonomous process.

It is part of the operating model.

The same applies to the articles we publish

That principle extends beyond software.

We also use large language models when developing written content.

There is little reason not to.

A language model can help explore a subject, organise an argument, identify gaps, propose alternative structures or turn a collection of rough thoughts into a coherent first draft.

It can also challenge the author. Asking a model to find weaknesses in an argument, identify missing perspectives or explain where a technical claim is unclear can be extremely useful.

This article itself was produced with AI assistance.

But that does not make the model responsible for what appears on this website.

The responsibility belongs to the human author.

That means deciding what we actually want to say before and during the writing process. It means rejecting suggestions that do not reflect our experience or views. It means correcting inaccurate statements, reshaping arguments, checking claims and making the final editorial decisions.

An LLM can generate plausible prose about almost any subject. Plausibility alone is not a sufficient publishing standard.

The important question is whether a knowledgeable person is prepared to stand behind the finished piece.

The tool can assist with authorship. It cannot assume accountability for it.

AI-assisted work is not delegated responsibility

As AI systems become more capable, the temptation is to frame the discussion as a competition between human and machine work.

We think that framing misses the more useful question.

AI can already perform tasks that would previously have required substantial human effort. That capability will continue to improve.

The opportunity is to use that capability deliberately.

In software development, AI can compress hours of exploration and implementation into much shorter cycles.

In audits and reviews, it can examine more material than a human could reasonably inspect in the same amount of time and surface patterns worth investigating.

In architecture and product work, it can be an effective analytical partner.

And in writing, it can help turn ideas into clearer arguments.

But there is a difference between using AI to extend human capability and delegating responsibility to AI.

We are enthusiastic about the first.

We remain cautious about the second.

The more capable the tools become, the more important it is to know who is maintaining the wider picture, who is exercising judgement and who is prepared to sign their name to the result.

For Microcorem, that answer remains human.