Office workers are building apps: AI skills for 2027

An employee spots a recurring task, describes it to AI and gets a small application: an export reconciliation tool, request form, report or document-preparation utility. That is another level of autonomy beyond asking for a draft email.

Managers can see the appeal: the specialist understands the process and can test an idea sooner. For employees, it is a way to extend their capabilities. However, the claim that everyone unable to build applications will face dismissal from 2027 is not supported by the cited Gartner forecast.

This is the first article in a series about office development with AI. It covers skills and work organization. Part two examines security; part three considers the historical NC3A case and service architecture for people and agents. Sources were checked on November 1, 2026.

In Gartner’s forecast, the share of employees obtaining, adapting or building technology beyond IT oversight rises from 41% in 2022 to 75% in 2027. This concerns a broad range of technological behavior. Buying a service, configuring a tool and writing software share that wording; it cannot be interpreted as a percentage of programmers. Gartner: The CISO for Digital Business — employee technology forecast ↗

The forecast does not say all employers will introduce an identical job requirement or start dismissals on a particular date. Nor does it establish that dismissals are already caused specifically by an inability to build applications. Those claims need evidence about actual staffing decisions and their reasons.

An ILO research brief dated April 17, 2026 separately explains that potential AI exposure indicators are not forecasts of job losses. They describe opportunities for task change without accounting for every adoption constraint or economic consequence. ILO: Workers’ exposure to AI — what indicators tell us and what they don’t, April 17, 2026 ↗

For a company, the practical implication is to develop skills and rules for self-service automation. A year in an analytical forecast should not become an artificial dismissal deadline.

An employee who can turn a work problem into a checkable tool gains another way to improve a process. It might be a small form, table transformation or draft summary. Not every local task needs an entire information system.

Citizen development extends familiar practices involving macros, spreadsheets and corporate-platform customization. Generative AI adds the ability to describe software behavior in ordinary language and obtain an initial implementation or interface.

An accessible first draft does not remove the need to understand its result. Someone must explain where data comes from, what counts as correct, which exceptions are acceptable and what happens on failure. That knowledge is often closer to the specialist’s work than to a particular LLM’s internals.

For some roles, the next step will be building small tools. For others, it will be using existing automation, checking data or defining requirements. Digital autonomy can develop in different ways; expecting identical development proficiency from everyone would be unreasonable.

Assess the ability to take a task from description to an accepted result, rather than counting prompts learned. The following is our proposed training matrix, not a forecast of every employer’s requirements.

An employee may know that “shipped” in one export means handover to a carrier, while in another it means receipt by the customer. Without that distinction, an application could neatly combine incompatible statuses. Defining the rule matters more than the confidence of AI-generated code.

Or a program silently excludes a record with a missing date. Its user should notice that it made a substantive decision without an agreed rule. A good task specification requires showing those records separately and explaining why the result is incomplete.

Consider a fictional pilot. A manager assembles a weekly order summary from several CSV files and wants discrepancies plus a draft report. Initially, the program works only with prepared copies and changes nothing in the source systems.

The employee describes columns, order identifiers, return handling and status meanings. A data specialist helps define when records may be joined. AI then helps build an upload form and reconciliation logic.

Testing starts with a small set already reviewed manually. It contains a duplicate identifier, missing date, return and two similar customer names. The expected result includes correct records and questions the program should ask instead of guessing.

After matching the reference result, add cases and check that earlier behavior remains intact. Preserve the tool version, rules and test files. Then decide whether it can enter routine use and who owns changes.

This is autonomy within defined boundaries. Access to a production database or sending the report to a customer creates a new approval stage. A successful reconciliation of copies does not automatically authorize those actions.

A project needs a specific task and completion condition. “Build an assistant for the whole department” is difficult to verify. “Produce discrepancies from approved exports, show evidence and save a result for review” provides a clearer scope.

Measure preparation and review time together. An attractive screen creates little value if someone must recalculate every record manually. Also track omissions, incorrect joins and cases where clarification was appropriately requested.

Include format changes, dependency updates and handover to another person in the assessment. If only its author understands the application, the company gains another dependency on one individual.

A small tool therefore needs a short description: purpose, inputs, owner, how to run it and how to return to the manual process. Scale documentation to the consequences of failure rather than the apparent complexity of the interface.

Instead of requiring everyone to build something with AI, collect recurring frustrations. Where are people copying the same data repeatedly? Which reports differ only in presentation? Which checks are routinely missed? These tasks make value easier to establish.

Provide approved tools, training time and safe learning data. IT helps with templates, access and review. The process owner explains the rules. Employees build or configure solutions within their competence.

Microsoft’s Power Platform adoption guidance also distinguishes makers, administrators, platform owners, security specialists and support. User autonomy coexists with accountability and governance. This illustrates one platform’s organization; it does not prescribe a product choice for AI Office. Microsoft: Power Platform adoption roles and responsibilities ↗

Start with a few willing participants and one task category. After a pilot, assess which templates are suitable for others. This teaches people to work with outcomes rather than competing over the number of applications generated.

Tokens are one cost component. Data sources, permissions, hosting, integrations, backups, licensing and support remain. Some tasks are better addressed by configuring an existing product; others justify custom development.

A self-built form does not automatically replace an accounting, HR or contract system. Once several departments depend on an application, availability, compatibility and change control become requirements. That is a reason to move it to an appropriate support tier.

Microsoft describes a low-code application lifecycle through requirements, development, testing, deployment, operations and change management. A lower creation threshold does not remove these stages. Microsoft: Application lifecycle management with Power Platform ↗

Large staffing cuts are not the only strategy either. In September 2026, Gartner warned about cutting too deeply and too soon for savings and recommended developing skills and preserving institutional knowledge. This is an analytical position, not a guarantee against dismissals. Gartner: Four shifts shaping the future of work, September 9, 2026 ↗

AI Office helps build checkable workflows around company data. The prototype includes permission-aware document retrieval with evidence references, code-calculated proposals, approval bound to a specific version and local tasks. Its Analyst Council examines questions through several roles of one model.

These can provide foundations for bounded workflows. An employee might help specify a catalog check or task-preparation form while calculations and approval remain in the application. The current prototype is not a universal builder for arbitrary employee applications.

We do not propose granting every new application access to all documents, accounting and corporate email. The prototype also lacks ready connectors to those external systems. Self-service scenarios need separate design and evaluation.

First, choose a recurring task and describe it in ordinary language. Second, prepare anonymized or fictional examples with known results. Third, build a small tool and test exceptions. Fourth, establish ownership, permissions and conditions for real-world use.

A suitable learning task is one the employee understands well enough to detect errors. Real secrets and critical-action permissions should not quietly become part of a training project.

A strong outcome is someone who can explain their tool, demonstrate checks and acknowledge limits. That skill is useful regardless of tomorrow’s staffing changes. The sources do not establish guaranteed dismissal for everyone else.

We can examine your workflow and choose an initial AI Office scenario: a clear task, bounded data and acceptance criteria for the employee and manager. The following articles examine security and shared service access for people and agents.