Beyond the Chat Window: AI Agents, Work, and the Individual Engineer

At IBM, I won the Bobathon as a solo-member team within ISDL. The event involved hundreds of teams, including teams with multiple members.

That experience belongs alongside some rather ordinary uses of AI in my life: working on software projects, configuring my router and camera, organising financial information and reminders, tracking health-related information, and revamping both my personal and technical websites.

The range is what interests me. I do not arrive at each of these projects knowing every protocol, tool, or framework involved. With some engineering aptitude and a reasonable approach, I can ask the agent to do much of the reading, write the supporting code, and document what we find. I still need to decide what I want, question its assumptions, and check what actually happened.

That is a very different kind of assistance from completing the next line of code.

Meanwhile, enterprises are trying to decide how many people they need. Some have cut roles, discovered work that still needs humans, and adjusted. Others continue restructuring. There is a temptation to turn all of this into one simple verdict about AI replacing people.

I think the more useful question is what has actually become possible, and what still determines whether it works.

Four Years of Changing What We Delegate

These developments overlap. Tool use, reasoning, and coding assistance did not arrive in neat, separate generations. But the shift in what a developer can delegate is substantial.

Open the timeline illustration at full size.

Period	A concrete development	What changed in the work
2022-2023	GitHub Copilot became generally available in June 2022; ChatGPT launched that November; OpenAI introduced function calling in June 2023.	Code suggestions and explanations became readily accessible, with application developers gaining a structured way to connect models to tools.
2024	OpenAI introduced o1 in September, reporting improvements from additional training and test-time computation.	More inference effort could be spent working through a difficult problem before returning an answer.
2025	Codex’s May launch put a software-engineering agent inside a repository-backed execution environment.	Reading files, editing code, running checks, and revising an implementation became part of one delegated workflow.
2026	Models such as GPT-6 Astra, GPT-6.1 Sol, Gemini 4 Argon, and Claude Opus 5.5 support increasingly demanding reasoning and agentic work.	Broader investigations and longer tasks become practical targets, with context handling, permissions, and verification determining how far delegation should go.

The launch records are linked in the references. In my September 2024 o1 article, I was interested in reasoning before answering. What matters now is that reasoning can be connected to observations from the actual development environment.

A longer explanation of a PTP property is still an explanation. A response from the camera is an observation.

What the 2026 Numbers Show

OpenAI documents GPT-6 Astra for demanding reasoning and coding, and GPT-6.1 Sol for complex work at a lower cost. Google and Anthropic describe similar ambitions for Argon and Opus 5.5. Those descriptions need to be examined at the task level.

For example, Google’s October Argon model card publishes these results:

Benchmark	Gemini 4 Argon	GPT-6 Astra	Claude Opus 5.5
DeepSWE v1.1	77.9%	74.1%	74.2%
Terminal-Bench 4.0	57.4%	58.2%	66.4%

The ordering changes with the workload. This particular comparison does not include Sol.

The methodology matters: Google describes single-attempt evaluation without majority voting or parallel test-time compute, generally at its highest thinking settings. It computed Argon’s DeepSWE results with a mini-swe agent harness; comparison results come from leaderboards and provider reports. These are published results assembled under the stated conditions, not my own controlled run with identical budgets and tools.

A practical account is sometimes more illuminating. In an October 2026 report, OpenAI engineer Rodrigo Roim describes Astra gathering evidence from past pull requests, internal discussions, and production profiles before proposing code removals. For a stale-experiment audit, he reports 142 findings from Astra Ultra and 131 from Sol Ultra, at API costs of $109.06 and $15.12 respectively. He reviewed the findings and describes classes Sol missed.

That is a vendor employee’s account of a particular workflow, not a universal price-performance ranking. What makes it useful is the connection between the task, the evidence, the review, and the cost. The improvement is more concrete than a model sounding confident about a repository it has never inspected.

The Model Needs Somewhere to Work

The language model is not the entire agent. It needs software around it to assemble context, execute permitted tools, retain useful state, and return observations. I use harness for that surrounding system.

A simplified execution loop looks like this:

flowchart TD
    C[Objective, project guidance and selected evidence] --> M[Model chooses next action]
    M --> R[Runtime checks tool request and permissions]
    R --> T[Permitted tool executes]
    T --> O[Output, errors and exit status]
    O --> C
    M --> S[Return result or stop with unresolved issue]

OpenAI’s account of the Codex harness describes this separation. Better model reasoning helps, but so do useful tools, good error messages, access to the right records, and a clear stopping condition.

The harness makes observation possible. The model still has to interpret it correctly. A compiler can reject a type error; it cannot decide whether the program is solving the right problem. A test supplies evidence about the case it exercises, not a certificate for the entire implementation.

Getting More Out of My Nikon Z6

I wanted to configure my Nikon Z6, understand the settings it exposed over USB, and save a record of the configuration. I knew very little about PTP - the Picture Transfer Protocol used for this communication. I had not sat down and studied the protocol before starting.

The AI agent helped with that part. It worked through documentation and existing tools, wrote the code needed to inspect the camera, and kept notes on the responses. My part was to explain what I wanted, keep the investigation bounded, and question whether the evidence supported the next step. I could work through an unfamiliar interface without first becoming its resident expert.

We started by reading, rather than changing, the camera’s settings. Using gPhoto2 and Apple’s ImageCaptureCore on my Mac, the investigation established what the camera advertised and what it actually returned when queried. It advertised 84 operations. That did not mean we had tested 84 operations, much less that it would be sensible to invoke all of them!

From there, I worked on configurations for portraits, action, and landscapes. Since I mainly use JPEG, image quality was another practical concern. We configured JPEG Fine-star and checked the values returned by the camera. The tools checked existing settings before proposing changes and read them back after writing. Repeating the quality configuration when the target values already matched produced no further writes.

I also saved snapshots of the settings read from U1, U2, and U3. Those gave me a documented record of the presets, rather than leaving the configuration scattered across camera menus and a long AI conversation. They are settings snapshots for comparison and reconstruction; Nikon’s own in-camera save/load settings file is a separate form of backup.

The documentation mattered as much as the code. There were notes on what had been read, what had been changed, and what remained untested. A successful settings readback, for instance, does not establish that autofocus will perform better when I take the camera out. That still needs photography.

For me, this was a useful change in how a side project gets done. I did not have to read every protocol document myself or write every decoder from scratch. But I did need enough understanding to distinguish inspecting a setting from changing it, and a saved value from a tested photographic result. AI helped me get further into the work; it did not remove those distinctions.

The Router, the Reminders, and the Websites

The same approach has found its way into rather ordinary things at home. I have used AI to help configure my OpenWrt-based router, investigate the network, and work on reboot automation. There is a fair amount of configuration, scripting, and documentation involved in something that most of us would prefer to set up once and forget.

Here too, asking a useful question matters. A router responding to a ping does not explain why an application buffers. A script successfully checking access to a reboot interface does not tell me whether the scheduled job later ran and the connection recovered. The agent can help inspect each part, but I still need to keep the original problem in view.

Financial reminders, vehicle history, and health-related tracking are other examples from my own use. These are less dramatic than a coding benchmark, but keeping information organised and making it easier to follow up is useful work. With financial or health information, I also need to pay attention to what the agent is allowed to read and where that information goes.

Both my personal and professional websites have been revamped with AI assistance. These projects involve different tools and different kinds of information, yet I can approach them with the same combination of a clear objective, an agent that can inspect and act, and checks on the result.

I have not measured a productivity multiplier across these projects. What I can say is that I am attempting work across more areas, including interfaces I knew little about when I started. The reading and coding have become easier to delegate. Deciding what is useful, and when the result is good enough, still takes thought.

Enterprises Cannot Reorganise Around a Demo

The enterprise story is less tidy than either the sales pitch or the backlash suggests.

Klarna is a useful case. In February 2024, it promoted its assistant as doing work equivalent to 700 full-time customer-service agents. By May 2025, the company was recruiting for a human-support pilot. Its spokesperson told CX Dive that customers should always have the option of speaking with a person. The same reporting records the CEO’s acknowledgement that an excessive focus on cost had hurt quality.

But this was not the end of AI at Klarna. In February 2026 reporting on the CEO’s 20VC interview, human service and AI remained part of the plan, while he expected headcount to fall below 2,000 by 2030. That was a future expectation, not evidence of another completed round of layoffs. Hiring for some human interactions can coexist with pressure to employ fewer people overall.

The broader evidence also needs its denominator. Robert Half’s 2026 research summary says 32% of surveyed U.S. hiring managers who had eliminated positions later reinstated the same or similar roles after adopting AI. That is a report from a selected group of respondents, not 32% of all employers or workers. Gartner’s 28 October forecast that 30% of AI-replaced employees will be rehired by 2029 is a prediction, not a rehiring count already observed.

Renewed restructuring is real too. Amazon announced approximately 14,000 corporate-role reductions in October 2025, followed by approximately 16,000 roles in January 2026. Its explanation emphasised reducing layers, ownership, and bureaucracy; the October message also discussed AI as a reason to move quickly. Those statements do not prove that an AI agent had replaced each affected employee’s work.

Conceptual workforce cycle; company paths vary. Microsoft's 26 October 2026 announcement confirms the voluntary exit offer shown, without establishing completed departures or attributing individual roles to AI replacement. View full size.

My concern is the order of decisions. A role includes exceptions, institutional knowledge, relationships, and responsibility for the outcome. Automating some visible tasks does not establish that the rest of that work has disappeared. Companies need to understand the workflow and measure service quality before treating a model’s capability as a headcount calculation.

That does not mean AI cannot reduce staffing needs. It means the claim should be tested against the work, including what happens when the ordinary process fails.

Why More Capability Comes With More Boundaries

An assistant that returns text can give bad advice. An agent with a shell, network access, and credentials can act on it. As the set of possible actions grows, the execution boundaries become a more important part of the system.

For my kind of projects, I would distinguish several controls:

• Filesystem and network permissions limit what the runtime can reach. A repository-editing task need not expose unrelated personal records or every service on the network.
• Credentials should be scoped to the job. Being able to inspect a configuration is different from having unrestricted administrative access.
• Approval should occur where consequences warrant it, such as changing a live network, sending information externally, deleting data, or publishing a result.
• Logs, before-values, backups, and tested recovery procedures make changes inspectable and, where possible, reversible. A backup is useful only if its coverage and restoration limits are understood.

These are engineering choices, not a request for confirmation before every harmless file read. Too many interruptions can make a tool impractical; too much authority can make a mistake consequential. OpenAI’s permission documentation also makes a useful distinction: a command sandbox is not a universal boundary for every connector, browser, or hosted tool. Each route needs its own access controls.

There is also prompt injection. Instructions hidden in a retrieved page, a repository issue, or a tool result may try to redirect the agent. The source can be relevant evidence without having authority to change the task. OpenAI’s agent-safety guidance discusses this risk and the need for layered controls; no prompt alone guarantees prevention.

Not every restriction has the same purpose. Some controls address misuse or security. Others reflect organisational policy, privacy obligations, product availability, subscription limits, capacity, or pricing. Anthropic’s Opus 5.5 announcement, for example, describes verification programmes for particular biology and cybersecurity uses. That is a different boundary from a local sandbox refusing an unauthorised file write.

I would judge a restriction by what it protects, how clearly it is explained, and whether the permitted path still lets the useful work get done.

Apple Intelligence, Gemini, and the Privacy Question

I have been disappointed by AI promises too. In The Apple Intelligence Saga: From Hype to Disappointment, I wrote about buying the iPhone 16 Plus with considerable expectations of Apple Intelligence. The experience did not live up to them. That is part of why I am reluctant to buy hardware on the strength of features promised for later.

Apple has since taken a substantial turn. In their 12 January 2026 joint statement, Apple and Google announced a multi-year collaboration, with the next Apple Foundation Models based on Gemini models and cloud technology. Apple then announced the English beta rollout of Siri AI on 14 September, describing models built with Google and capabilities including personal-context understanding and actions across apps.

So there is a released product to discuss, beyond the partnership announcement. That does not establish that every earlier promise has been fulfilled, or that I have personally tested the new Siri and found it satisfactory. Google’s contribution is significant; Apple still has to make the complete experience work.

The privacy story needs a closer look too. In June, Apple’s security team described extending Private Cloud Compute to Google Cloud, using NVIDIA GPUs for demanding workloads. Apple says the design retains stateless processing, no privileged runtime access, attestation, and software transparency, with Apple controlling the PCC software. Some processing remains on device; some can run in this cloud environment.

Those are meaningful engineering protections. A Google-hosted machine does not by itself establish that Google can read the request. Equally, a familiar Apple interface does not mean that every computation stays inside the phone. The hardware, software, access controls, and verification all matter. This is the published architecture, not a security audit I have performed.

There are separate choices around the interaction data. Apple’s Improve Siri & Apple Intelligence policy, updated on 30 October, says that opting in allows collection of interactions, including audio and transcripts, for improving Siri and training foundation models. Apple describes removing personal details and using identifiers separate from the Apple Account. It also allows review of a subset and retention for up to two years, with reviewed material potentially kept longer. That optional collection is distinct from PCC’s handling of an individual inference request.

An external chatbot extension is another path again. Apple’s ChatGPT extension terms distinguish use without an account from use while signed in, when the user’s account settings and OpenAI’s policies apply. The Gemini-based Apple models should not be confused with sending a request to that extension.

This is where the grey areas become practical. Which route handled the request? What information went with it? Which improvement settings were enabled? Apple documents an Apple Intelligence & PCC Report that users can enable and export to inspect off-device requests. I would rather see those distinctions made understandable than accept a single privacy slogan for the whole system.

The same questions apply to the agents helping with my camera, network, and personal information. Greater usefulness can require more context and more access. I want that usefulness, but I also want to know what I am agreeing to.

Memory, Time, and the Cost of Finishing

The hardware questions have not gone away. In my earlier edge-inference article, I focused on memory bandwidth and runtimes. An agent adds more turns, tool results, and decisions to that workload.

For a conventional autoregressive transformer, prefill processes input context and decode produces subsequent tokens. Low-batch decoding often puts considerable pressure on memory bandwidth, while prefill offers more parallel work. These are tendencies that depend on architecture, batching, context length, and kernels, not universal labels. NVIDIA’s inference overview explains the basic distinction.

The KV cache stores attention keys and values. For a uniform full-attention configuration, an approximate unsharded payload size is:

KV bytes = 2 * layers * KV heads * head dimension
             * bytes per element * sum of retained sequence lengths

An illustrative 32-layer configuration with eight KV heads, head dimension 128, two-byte elements, and one sequence of 100,000 tokens needs about 12.2 GiB for that payload. It excludes overhead and temporary buffers; sharing, eviction, and sharding affect the actual allocation. This is arithmetic, not a measurement or a frontier-model specification.

Context engineering addresses a different problem. My workspace uses AGENTS.md for project guidance and SCRATCHPAD.md for current findings and the next immediate action. Those are ordinary documents, not model weights or the KV cache. They help when the relevant information is loaded and interpreted correctly.

In my camera work, a note saying the camera advertises this setting as writable, but we have only read it carries a useful limit. If a later summary reduces that to writable, the agent may act on a stronger claim than we established. More context capacity does not repair a misleading note. The qualification needs to survive when the working history is shortened.

Elapsed time also includes builds, tests, device responses, queueing, and retries. Faster token generation shortens only part of a task whose next decision depends on a slow test. Token prices likewise omit execution infrastructure and the time spent reviewing or repairing the result.

I would compare cost, elapsed time, and human intervention per accepted task, with the acceptance criteria fixed beforehand and failed attempts included. That is a proposed evaluation method, not a benchmark I have run across these models.

What One Person Can Build

This is where I find the opportunity most interesting. Researching an idea, building a prototype, writing code, debugging it, preparing documentation, and operating the result have usually drawn on several kinds of expertise. AI can help an individual move across more of those activities. It does not make all that expertise interchangeable.

A possible division of AI assistance across research, design, code, testing, documentation, and automation. The project board is illustrative. View full size.

There is a public example worth examining. Maor Shlomo’s July 2025 Base44 interview describes bootstrapping as a solo founder with extensive AI-assisted coding. Wix announced the acquisition on 18 June 2025, with approximately $80 million in initial consideration plus conditional earn-outs. Its announcement also refers to Base44 employees: solo founding should not be confused with remaining a one-person organisation throughout.

That example establishes a possibility, not a typical outcome. It does not give every prototype customers, distribution, revenue, or a sustainable business.

My Bobathon win is a personal example of competing as a one-person team, not proof that I have already built such a business. The router, camera, software, and website projects show areas where I am putting these tools to use. Turning any project into a product would still require deciding whose problem it solves, whether they would pay, and whether I can support it reliably.

The enterprise and individual stories meet here. An enterprise has existing obligations that do not vanish when a tool improves. An individual gains room to attempt work that might previously have remained an idea. In both cases, useful delegation depends on understanding the work.

The Costs Do Not Disappear

I remain concerned about the wider bill. Micron’s fiscal 2026 disclosures describe AI-driven memory demand and supply allocation towards data centres. The memory squeeze has consequences beyond model subscriptions, though it does not explain every rupee of a finished device’s price.

I am disappointed by Apple’s pricing in India. My advice to readers, friends, and family remains to buy less often and keep supported phones and computers that still meet their needs. Improved hardware does not automatically make an upgrade necessary.

There is a carbon and water cost too. The IEA’s 2026 analysis estimates global data-centre electricity use at 485 TWh in 2025 and projects about 950 TWh in 2030; those totals include workloads other than AI. Its October report discusses electricity-related emissions, water stress, and cooling tradeoffs. Manufacturing and constructing the infrastructure add further costs.

Those concerns deserve their own detailed treatment. For this discussion, they reinforce a practical point: more generated work is not automatically more useful work. The cost of a task includes resources as well as money and attention.

I am enthusiastic about what I can now try with AI. I am also interested in what survives testing, what helps someone, and what is worth maintaining. That is where the engineering becomes more demanding, even as writing the code becomes easier.

Warm regards,

D K Bhargav Achary

References

• GitHub and OpenAI - GitHub Copilot is generally available, June 2022; Introducing ChatGPT, November 2022; Function calling and other API updates, June 2023; Learning to reason with LLMs, September 2024; Introducing Codex, May 2025.
• OpenAI - GPT-6 Astra and GPT-6.1 Sol, documentation checked October 2026; Rodrigo Roim, Maintaining software with the GPT-6 family, 14 October 2026.
• Google DeepMind - Gemini 4 Argon model card and evaluation methodology, October 2026. Scores are attributed to this publication, not independently reproduced here.
• OpenAI and Anthropic - Codex as a platform, August 2026; Permissions and Safety in building agents, documentation checked October 2026; Introducing Claude Opus 5.5, September 2026.
• CX Dive - Kristen Doerer, Klarna changes its AI tune and again recruits humans for customer service, 9 May 2025; Klarna pursues Uber style customer service model, 20 February 2026. The former includes direct company-spokesperson reporting; the latter reports the CEO’s 16 February 20VC interview.
• Robert Half and Gartner - Labor market outlook through year-end 2026, 2026; Gartner predicts 30% of employees replaced by AI will be rehired by 2029, 28 October 2026.
• Amazon - Beth Galetti, Staying nimble and continuing to strengthen our organizations, 28 October 2025; Update on our organization, 28 January 2026.
• Microsoft - Amy Coleman, Introducing a Voluntary Exit Offer, 26 October 2026.
• Lenny’s Podcast and Wix - The Base44 bootstrapped startup success story: Maor Shlomo, 6 July 2025; Wix acquires Base44, 18 June 2025.
• Apple and Google - Joint statement, 12 January 2026; Apple, Siri AI is here, 14 September 2026; Expanding Private Cloud Compute, 8 June 2026.
• Apple - Apple Intelligence & Privacy and ChatGPT Extension & Privacy, updated 14 September 2026; Improve Siri & Apple Intelligence & Privacy, updated 30 October 2026.
• NVIDIA - Mastering LLM Techniques: Inference Optimization, November 2023. KV sizing here is an illustrative uniform-configuration calculation.
• Micron and IEA - Micron fiscal 2026 annual report; Key Questions on Energy and AI, April 2026; Powering Artificial Intelligence, October 2026.