↓ Skip to main content
J.K.

Using a code agent on my portfolio — first experiences

·619 words·3 mins
Jonathan Kudsk
Author
Jonathan Kudsk
Datamatiker student · Backend, data & web
Table of Contents

Assignment: Write about code agents and my first experiences using them.

What is a code agent (in practice)?
#

In the course, a code agent is more than a chat box. It can:

  • Read and edit files in the project
  • Run terminal commands (build, install, test)
  • Iterate across several steps toward a goal

Examples include Cursor Agent, Claude Code, Codex-style tools, and similar IDE integrations.

The developer still owns architecture and correctness. The agent is a fast assistant — not a substitute for understanding what ships to production.

Where I used it on this portfolio
#

I used a code agent heavily while building:

  • Hugo + Blowfish layout tweaks (header, footer, hero, contact page)
  • The floating chat widget (modal UI, localStorage conversations, typing state)
  • The Node chat API (server/index.js, server/rag.js)
  • CSS for glass-style UI and responsive chat layout
  • .gitignore and docs so secrets and build output are not committed

Typical prompts looked like: “Make the chat fill the center of the screen”, “Add multiple saved chats”, “Wire POST /chat to OpenAI with RAG from markdown files”.

What went well
#

Speed on boilerplate. Repetitive Hugo partials, CSS for the chat shell, and fetch/error handling in JavaScript were much faster than typing everything from scratch.

Exploration. When I was unsure how Blowfish loads scripts, the agent could search the theme and suggest extend-head.html for a custom bundle — a pattern I might have missed on my own.

Consistency. After the first chat styles existed, follow-up requests (“bigger modal”, “typing indicator”) stayed visually aligned because the agent edited the same custom.css conventions.

What I had to watch out for
#

I still need the theory (Naur). Generated code can compile and still break the design — wrong z-index, duplicate listeners, or API keys in the wrong layer. I reviewed every change to the security boundary: browser → my API → OpenAI, never key in Hugo.

When we wired the LLM, I made sure the posts document the real setup: OpenAI key in server/.env, ragApiUrl in Hugo only, and .env in .gitignore. I describe that flow in AI-driven application as if fully deployed — that is the intended production setup even when I am not running the API every day during development.

Over-scoping. The agent sometimes refactors unrelated files. I kept diffs focused and rejected “cleanup” that was not part of the task.

False confidence. A working hugo build does not mean RAG is correct. I verified embeddings, rag-data content, and real chat questions manually.

Course vs portfolio. The exam assignment about assessing student reports with JSON is a different app than this chatbot. The agent helped on both ideas, but I separated portfolio assistant from assignment assessor in my head so requirements did not mix.

How I collaborate with the agent
#

  1. Describe the outcome — user-visible behaviour first (“FAB opens modal, history persists”).
  2. Point to constraints — Blowfish theme, no secrets in frontend, match existing CSS.
  3. Review the diff — especially server/, params.toml, and anything touching auth or env.
  4. Run commands myself — hugo, npm start, open the browser — to confirm.

That matches spec-driven thinking from the course: clear intent, accept criteria, then implementation.

Reflection
#

Code agents changed how fast I could ship UI and integration glue. They did not remove the need to understand RAG, HTTP, or where API keys live. For a datamatiker portfolio, the best result is showing both: a working feature and the ability to explain why it is structured that way — which is exactly what these exam blog posts are for.

My takeaway: use the agent as a pair programmer, keep architecture and security in your own hands, and always run the app once more after the agent says it is done.