Future of Software Engineering in the Age of AI Agents at Cyber Nexus 2.0 - CSS - MUET

The future of software engineering is not about typing code faster. It is about directing AI agents, checking their work and owning the result. I shared this view in a 60-minute talk at Cyber Nexus 2.0, the hackathon run by the Cyber Security Society at Mehran University of Engineering and Technology, MUET. The talk moved from vibe coding to agentic engineering. This post covers the main points of the talk, with the stories, the safety rules and a plan for students.

Why software engineering is more than coding

Coding is one box on a big map. The map also holds requirements, design, testing, quality checks, project management, release management, maintenance, security and ethics. A working engineer touches all of them.

The classic software development life cycle has eight stages. They are feasibility, planning, requirements, design, implementation, testing, deployment and maintenance. This process grew from one belief. Writing the code is the slow and costly part.

That belief is now weak, because agents write code fast. But people still decide what to build, review the result, test it, release it and keep it running. Those steps still move at human speed.

So faster coding alone does not finish a project sooner. An Anthropic playbook made the same point, that build gets fast and the human-speed steps around it do not. Those steps become the limit. The lesson is to learn the whole map, not only the code.

Vibe coding, AI engineering and agentic engineering

Vibe coding is a way of building where you forget that the code even exists. Andrej Karpathy named it in February 2025, and Collins Dictionary made it Word of the Year for 2025. Tools like Lovable, Bolt.new and v0 by Vercel let you describe an app and get a working one. That is why it is fun.

The trade-off is simple. If you stop reading the code, nobody checks it. Karpathy said he accepts every change and no longer reads the diffs, which are the lists of changes. This suits throwaway projects and demos. It is a poor choice for anything people will depend on.

The talk then showed three ways of working. In AI-assisted development, you write the code and the AI suggests, completes and explains. In AI engineering, you build applications on foundation models, which are large pretrained models, using prompts, RAG, tools, agents and evaluation. In agentic engineering, agents write the code and you orchestrate them and act as oversight. A year after his first post, Karpathy said professionals now work this way, with more oversight.

The building blocks of AI engineering

The API. A model is reached over plain HTTPS. You send a message with your key and a version header, and you get a response. Official kits exist for Python, TypeScript, Go, Java and more.

Prompts. A weak prompt says only, summarize this report. A strong one says you are an analyst, write five bullets for a non-technical reader, quote figures exactly and say so when unsure. Be specific about the role, the audience, the format and the limits.

Evals. An eval tests a prompt, the way a unit test checks code. Code-based grading is fast, reliable and scales well, but it lacks nuance. Model-based grading lets a model score the output, for example from one to ten.

Tools and MCP. With tool use, the model asks to call a tool, your code runs it and returns the result, and the model answers. The Model Context Protocol, or MCP, is an open standard that Anthropic published in November 2024. You build a connection once, and many agents can use it.

The harness. This is the runtime around the model. It holds the loop, memory, skills, subagents, tools, a sandbox and an interface. The same model in a different harness is a different product.

Workflow or agent, and which steps do I control?

A workflow is a system where models and tools follow paths written in code. An agent is a system where the model directs its own process and tool use. Anthropic's guide on building effective agents names five workflow patterns. They are prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer.

The real question is how much freedom to give. I keep the steps where a mistake costs the most. In plan mode, the agent first researches in read-only mode and proposes a plan. I approve it, and only then does the agent run.

The talk also gave an order for adopting these habits. First, write down your intent, set up feedback loops and use plan mode. Next, add skills, subagents and evals. Then wire in pull request review and automatic build and test checks. Files such as intent, spec and plan move between stages in version control, with review gates. Human judgment stays central.

What goes into an agent's context

The model sees only what is in its context window, the limited space for everything it reads in one run. It holds the system prompt, tools, memory, chat history and retrieved documents. Deciding what goes in is the job.

RAG cuts documents into chunks, turns them into searchable numbers, retrieves the best chunks and generates an answer. Agentic search lets the agent think, search, read and repeat. The creator of Claude Code said early versions used RAG with a local vector database, but agentic search generally worked better.

My first story was a lab plan. I asked how many students fit if an empty room became a lab. No Autodesk MCP was available, so I used an open source one called AIBlueprint, with FreeCAD to preview the drawing. I gave it my hand sketch with exact measurements and made changes by chat. In version five, the room was about 16 feet by 15.5 feet, with two tables, desks on both walls, a clear instructor zone and room for the door to swing. Twenty-one students fit, nine at wall desks and twelve at tables.

My second story was my tax return. The agent first read Pakistan's tax laws and rules into memory. Then I gave it my documents, and it filled the FBR tax portal through browser MCP while I watched. It did better than my lawyer the year before and taught me a few things. My finances were simple, and I reviewed everything. The lesson is to make the agent understand first.

One rulebook for every AI tool

I keep one global rulebook in a Git repository. One small tool renders it into Claude Code, Codex and OpenCode. Another syncs 29 skills to six agent tools. A skill is a folder with an instruction file, and many tools support the format.

One rule says what to do when an instruction looks non-standard or suboptimal. The agent must stop, name the problem, give a better option with the reason, and let me decide.

When an agent makes the same mistake twice, I fix the rulebook, not the prompt. I edit once, and every agent reads it. This saves time, because I do not repeat the same advice in every chat with every tool. Agents can also write their own memory, but the rules that matter stay in my hands.

Basic safety for agents

Agents read the outside world, so everything they read is untrusted input. In May 2025, Invariant Labs described a flaw in the official GitHub MCP server. A malicious issue in a public repository carried hidden instructions. This is called prompt injection. A user asked the agent to check the open issues. The agent then read private repository data and opened a public pull request that contained it. Secure connections are not enough on their own.

I follow three habits. First, add guardrails at each layer the talk describes: access, control, gateway, runtime and sandbox.

Second, use a sandbox, a closed space where a mistake cannot reach your machine. A container shares the host's kernel, the core of the operating system. A microVM, a tiny virtual machine, has its own kernel, so the agent cannot touch host files or the outside network.

Third, treat Git as the undo button. Give each parallel agent its own worktree, a separate checkout, so agents do not collide and bad work is easy to discard.

Computer science basics still matter

A tool that runs slowly keeps the agent waiting. The MCP TypeScript kit waits 60 seconds for a request by default. Complexity decides whether a call finishes. A tool whose work grows with the cube of the input can time out. Agents also live in the terminal, so Linux and shell skills are now AI skills.

The talk ended with a warning about relying on AI for thinking. The first source is a 2025 preprint, a paper shared before formal review, from MIT Media Lab. It had a small sample. Fifty-four people finished the first three sessions in three groups, which were language model, search and brain only. Brain activity was measured. The language model users showed the weakest connectivity and struggled to quote their own work.

The second source is a 2026 preprint with a hypothesis. The more we delegate, the less we practise. Its human figures are an analogy, and the 2026 one is an estimate. I treat both as signals, not proof. Use AI, and keep thinking.

A call to action for MUET students

Every department uses costly tools, and agents can reach them through MCP servers. My search found community servers for civil tools like ETABS, SAP2000, Revit and AutoCAD. QGIS has some, and Esri has a beta for ArcGIS. SolidWorks and ANSYS have community servers, and Ansys publishes its own. Electrical has an official one for MATLAB. Petroleum is the gap. I found none for IPM, CMG, tNavigator or KAPPA, which is not proof that none exists.

These are common industry tools, not MUET's own labs. Many servers already exist, so the value is often in checking them, fitting local standards, adding safety and making teaching material.

The plan has four steps. Pick a tool another department uses. Check whether an MCP server exists. Team up with that department and build it, or validate it and fit it to local standards. Then make it a final year project. Start with one tool and one department.

Build for real users, such as a shop, your society, an NGO or another department. I built my housing society's ERP, a system to run its daily work, for free. A few shipped projects, each with a live link, a clear README file and the problem you solved, beat a pile of certificates.

The future engineer stands above the loop

Software work is moving from a line to a loop. In the old line, one slow trip back meant a new release cycle. In the loop, a cycle takes hours, not weeks. The engineer stands above it, to instigate, direct and govern. The loop keeps running, and human judgment stays above it.

Special thanks to my wonderful student Ameer Ali for inviting me. I’m grateful to Engineer Saqib Hussain for presenting me with the shield and mentoring the student organizers.

Thank you also to Muhammad Raza Abbas, President of the Cyber Security Society and rest of the team.