DEV Community: Jose Bernard Lagumbay

AI Agents Are Changing Software Engineering: 4 Major IT Developments This Week

Jose Bernard Lagumbay — Sun, 08 Nov 2026 03:51:57 +0000

November 8, 2026 | AI, Software Engineering, DevOps, Cybersecurity

For years, developers have been told that artificial intelligence would transform software development.

In November 2026, we're seeing something more interesting than another AI model release.

The infrastructure, workflows, and security practices around software engineering are changing to accommodate AI agents.

We're moving beyond autocomplete and chat-based coding assistants toward systems that can plan tasks, modify codebases, run tests, and coordinate multiple development activities.

Four major developments this week highlight where the IT industry is heading.

And for developers, engineering teams, and technology leaders, they raise an important question:

Are our software development processes ready for AI agents?

1. Meta Acquires Conductor: Multi-Agent Development Is Becoming a Serious Business

On November 4, 2026, Meta's acquisition of Conductor, an AI coding startup, became public.

Conductor enables developers to coordinate multiple AI coding agents working across parallel workspaces.

Instead of assigning every task to one coding assistant, developers can organize work across multiple agents.

Imagine building a web application with separate agents handling:

Frontend components and interface implementation
Backend API development
Automated tests
Documentation and code analysis

The potential advantage isn't simply generating code faster.

It's coordinating independent development tasks.

Why this matters

For development teams, agent orchestration could eventually become another layer in the engineering toolchain, similar to CI/CD platforms and cloud infrastructure.

However, parallel agents also introduce new challenges:

Conflicting code changes
Shared application dependencies
Context synchronization
Repository access permissions
Increased pull request review workloads

Running five agents doesn't automatically make a team five times more productive.

The real engineering challenge is coordinating their work without sacrificing reliability.

Source: TechCrunch — Meta acquires AI coding startup Conductor

2. GitHub Is Preparing Its Infrastructure for Thousands of Coding Agents

On November 5, GitHub published details of its new Git storage architecture.

One of the most interesting findings came from its internal testing.

GitHub reported support for:

5,000 concurrent agents working against a single repository
7,200 pushes per second to that repository
Read traffic maintaining consistently low latency during testing

These are internal test results, not a claim that ordinary repositories currently experience this traffic.

Still, they reveal something important.

GitHub is designing infrastructure for a future where automated agents produce significantly more repository activity.

Why repository infrastructure matters

Traditional software development generally assumes that humans perform most repository operations.

Developers create branches, make commits, open pull requests, and merge approved changes.

AI agents can accelerate these activities and increase their frequency.

That introduces new infrastructure requirements:

Traditional development	Agentic development
Human-driven commits	Human- and agent-generated commits
Mostly manual task execution	Parallel automated tasks
Developer-led code changes	Agent-assisted implementation
Conventional review queues	Potentially higher-volume review queues
Human-paced repository activity	More frequent automated repository operations

This doesn't mean developers should maximize commits or pull requests.

In fact, more changes can create more review overhead.

The bigger opportunity

Developers may spend less time typing routine implementations and more time on system architecture, specifications, integration, and verification.

GitHub's November 6 article on agentic engineering reinforces this distinction: faster code generation doesn't automatically solve the work surrounding software delivery.

Sources:

3. AI-Powered Cyberattacks Are Increasing the Importance of Developer Security

Perhaps the most urgent development this week came from Microsoft Threat Intelligence.

On November 5, Microsoft published research describing threat actors using agentic AI tooling to identify exposed credentials in public GitHub repositories and abuse compromised cloud access.

In one observed incident, an AI agent progressed from identifying exposed secrets to extracting data from Azure Key Vault in approximately five minutes.

This isn't evidence that every AI agent is dangerous.

It demonstrates how automation can accelerate existing cybersecurity threats.

The lesson for developers

Exposing an API key in a repository has always been a security problem.

But when automated tools can discover and exploit exposed credentials more quickly, the window for defenders to respond becomes smaller.

The same security fundamentals remain essential:

Never commit production secrets to repositories.
Use dedicated secret-management systems.
Apply least-privilege permissions.
Enable automated secret scanning.
Rotate credentials immediately if they become exposed.
Require explicit authorization for sensitive agent operations.
Review third-party dependencies and agent tool permissions.

Deleting an exposed credential from a repository does not make that credential safe again.

It must be revoked or rotated.

Agent permissions are part of application security

If a coding agent can access a production database, deployment environment, or privileged cloud account, its permissions become part of the system's security boundary.

A safer approach is to isolate agent execution and limit access to only what a task requires.

Agent-generated code should pass through the same security and deployment controls as human-written code.

Source: Microsoft Security — Threat actors use agentic AI tooling to find and abuse exposed secrets

4. Thoughtworks Highlights the Next Challenge: Scaling Agentic Engineering

On November 4, Thoughtworks published its analysis of macro technology trends for November 2026.

One of its central themes was the challenge of moving AI agents from small experiments into organization-wide software development.

A developer experimenting with a coding agent is very different from a company coordinating agents across dozens of engineering teams.

At scale, several questions become critical.

Context management: How do agents understand architecture decisions, coding standards, business rules, and acceptance criteria?

Cost management: How can teams measure the cost of successfully completed tasks rather than focusing only on token consumption?

Code review: Who verifies the growing volume of AI-generated changes?

Security: What systems can agents access, and who controls those permissions?

Platform ownership: Who maintains the shared infrastructure that agents depend on?

Thoughtworks describes the importance of an agent harness: the surrounding system that provides context, model access, evaluation, sandboxing, identity, cost control, and observability.

This is a significant development.

It suggests that platform engineering and DevOps practices may become even more important as agentic software development expands.

My interpretation

AI coding tools are becoming easier to access.

But operating them reliably across an engineering organization remains difficult.

The competitive advantage may increasingly come from how well teams integrate AI into their existing development practices—not simply which model they select.

Source: Thoughtworks — Macro trends in the tech industry, November 2026

What Should Developers Do Right Now?

You don't need an enterprise AI platform or an expensive multi-agent setup to start improving your workflow.

A practical approach is to introduce AI assistance into one controlled development process.

For example:

Step 1: Define the task clearly.

Create an issue with requirements, acceptance criteria, and constraints.

Step 2: Use an isolated branch.

Allow the agent to work on a feature branch rather than directly modifying the production branch.

Step 3: Require tests.

Validate application behavior, not just whether the generated code compiles.

Step 4: Review every meaningful change.

Check security, architecture, maintainability, and actual business requirements.

Step 5: Deploy through an existing release process.

Keep automated testing, staging environments, and production approvals in place.

A simple workflow might look like this:

GitHub Issue
    |
    v
Requirements and Acceptance Criteria
    |
    v
AI-Assisted Implementation
    |
    v
Feature Branch + Pull Request
    |
    v
Automated Tests + Security Checks
    |
    v
Human Code Review
    |
    v
Staging Deployment
    |
    v
Production Approval
    |
    v
Release + Monitoring

This workflow is not limited to AI-generated code. It's good engineering discipline that becomes especially valuable as automation increases.

Metrics worth tracking

Rather than measuring how many lines of code an AI agent produces, consider tracking:

Time from an accepted issue to a verified release
Pull request review time
Percentage of changes passing tests on the first attempt
Defects discovered after deployment
Cost per successfully completed development task
Number of changes requiring significant rework

These metrics provide a more meaningful picture of engineering productivity than code volume alone.

Will AI Agents Replace Software Developers?

I don't think that is the most useful question.

AI agents are changing the work developers perform, but producing code is only one part of building software.

Someone still needs to understand the problem, select appropriate architectural trade-offs, protect user data, verify behavior, and take responsibility for the final system.

AI may make implementation faster.

It doesn't automatically make requirements correct, architecture scalable, or software secure.

The skills that matter will continue to evolve.

I expect developers who combine strong engineering fundamentals with AI-assisted workflows to have more opportunities to build and maintain complex systems.

That includes understanding APIs, databases, testing, security, cloud infrastructure, and software architecture.

Final Thoughts

This week's developments point toward a broader change in the IT industry.

Meta's Conductor acquisition shows growing commercial interest in coordinating multiple coding agents.

GitHub's infrastructure work reveals the scale that agent-driven development could create.

Microsoft's security research demonstrates why automated development and cybersecurity must evolve together.

Thoughtworks highlights the organizational challenge of turning individual AI experiments into sustainable engineering practices.

These stories share one theme:

The future of software development isn't just about generating code faster. It's about building trustworthy systems that can coordinate human and AI contributions.

For developers, the opportunity is substantial.

But reliability, security, and engineering judgment will matter more—not less—as automation becomes more capable.

Let's Discuss

How are you using AI agents in your development workflow today?

Are they mostly assisting with individual coding tasks, or have you started experimenting with multiple agents working together?

And what has been your biggest challenge: code quality, security, cost, or reviewing AI-generated changes?

I'd be interested to hear how other developers are approaching this transition.

This article reflects developments reported through November 8, 2026. The practical recommendations and forward-looking views are the author's analysis, not confirmed industry outcomes.

SignalScape: Turning Camera-Derived Signals into a Living Forest

Jose Bernard Lagumbay — Sat, 07 Nov 2026 18:02:33 +0000

This is a submission for the Presage SmartSpectra SDK Challenge

What I Built

I built SignalScape, an experimental desktop experience where a virtual forest reacts to live, camera-derived pulse and breathing estimates. Rather than presenting those estimates as a health dashboard, I wanted to make human signals feel like part of a living landscape.

The project combines Angular, TypeScript, Electron, Three.js, and Presage SmartSpectra Node SDK 3.4.0. The visuals feature an illustrated forest with atmospheric lighting, fireflies and water effects, selectable background looks, and a reduced-motion option.

Two choices shaped the experience from the beginning:

Consent is explicit. Opening the application does not turn on the camera. Preview and measurement are separate user actions.
Unreliable data is not turned into certainty. Missing, stale, unstable or otherwise invalid estimates are withheld. The forest can remain calm without active measurements.

This is creative visualization, not a medical device, diagnosis, treatment, monitoring, or emergency-response tool.

Demo

Watch the SignalScape desktop recording: SignalScape — Turning Live SmartSpectra Signals into an Interactive Forest

The 3 minute 32 second Zight video shows the desktop interface, the opt-in webcam workflow, pulse and breathing estimates appearing on screen when available, visual backgrounds, quality-status changes and session shutdown.

The video intentionally shows the developer's own webcam and numeric estimates with their consent. The separate Showcase privacy switch can mask the camera preview and numeric readings in future recordings. The video does not display the Session details packet counter throughout, so I do not treat the screen recording alone as independent verification of every native SDK event or any physiological accuracy.

A live desktop demonstration requires the unpackaged developer build with the privately installed, authenticated SDK. The downloadable review installers are intentionally SDK-free and cannot perform native measurements.

Code

The source is public: jbrhinalyn/signalscape on GitHub.

To get the interface running locally:

git clone https://github.com/jbrhinalyn/signalscape.git
cd signalscape
nvm install
nvm use
npm ci
npm run dev

Open the Electron window. A clean npm ci intentionally excludes the proprietary native SmartSpectra SDK and developer credentials, so these steps show the interface and local camera preview, not authenticated live measurement.

For a real authorized developer session, use the repository's SDK and camera setup guide. It covers the optional pinned SDK, private key configuration, quality checks and live verification without committing a key.

Other useful references: architecture, privacy and data flow, and release boundaries.

How It Responds to Human Signals

SignalScape currently uses pulse rate and breathing rate, not HRV or expression recognition. The main flow is:

The person chooses Preview camera · Allow access, granting local video-only access. No microphone is requested.
Start measurement is a second explicit action. The Electron renderer captures bounded video frames and sends them through a constrained, typed IPC bridge to the main process.
The main process supplies those frames to SmartSpectra's custom-input interface. It decodes SDK events, adapts the rate estimates into a narrow data contract and returns sanitized events to the renderer.
A signal-quality state machine checks framing status, warm-up, numeric validity, confidence, stability and freshness. The UI shows a reading only while it passes these gates.
Only approved, fresh estimates feed the visualization engine. Pulse can influence water illumination and firefly glow; breathing can influence gentle movement. The decorative rhythm curves are animations based on rate estimates, not sampled physiological waveforms.

The distinction between frames received and metric packets produced matters. Receiving camera frames proves data transport, not successful SDK measurement. SignalScape exposes separate counters in Session details so a tester can check this boundary. Likewise, an attractive animated forest is not proof of measurement accuracy.

The forest still works as a visual experience when measurement is unavailable. Its ambient animation is separate from signal-driven effects, and reduced-motion settings remain available.

Design Choices and Trade-offs

One surprisingly important UX decision was making Stop measurement different from Stop camera. Stopping the SDK leaves the already-consented local preview running; stopping the camera releases the video tracks. Camera errors, permission loss, device disconnection and app exit also have explicit cleanup paths.

I added a manual Showcase privacy control for demonstrations. It overlays an opaque cover on the in-app video and hides numeric rates without altering measurement, consent or forest state. It is not a recorder, does not hide other desktop windows, and cannot substitute for reviewing the finished video.

The app is also intentionally conservative about packaging. Native SDK redistribution permissions, production credential handling, signed releases and physical-camera testing of SDK-enabled installers have not been established. Review installers therefore disable native measurement. A private developer key must never be embedded in a public Electron package.

Consent and Data Handling

Camera privacy is part of the interaction design rather than a last-minute dialog:

Collection and consent: Camera access starts Off. The user explicitly previews the camera, then separately starts measurement. No microphone access is requested. Anyone shown should agree to being recorded or shared.
Processing and sharing: SignalScape application code keeps the video preview local and passes temporary frame bytes through local Electron IPC to the native SDK. The UI receives only narrowed rate, status and aggregate-counter events, not raw SDK packets or the private API key.
Storage and retention: SignalScape has no built-in recording, measurement database, user account, cloud synchronization or application analytics endpoint. Camera frames and current estimates are kept transiently in application memory. Stopping the session releases the camera and clears in-memory measurement state; this does not erase OS or provider-side logs.
SDK telemetry and network: SmartSpectra's optional aggregate session telemetry is explicitly disabled with enableTelemetry: false and the SDK log level is set to none. SDK authentication/session authorization may still contact Presage services. SignalScape must not be described as fully offline, and the provider's internal behavior has not been independently audited.
Optional AI services: No AI service processes the live camera stream or generates the reported pulse/breathing estimates in SignalScape's application code.
External recording: The Zight demo is a separate, intentionally shared screen recording. Zight's storage, sharing permissions and retention are governed by that service, not by SignalScape's in-memory data policy.
Deletion and control: Stop camera stops video capture within SignalScape; closing the desktop app also releases the stream. Users manage any external video recordings with the recording provider. OS camera permissions and third-party logs have separate controls.

These are implementation and boundary disclosures, not claims about the SDK being clinically accurate or independently security-certified.