Junior Developers Can No Longer Write a Working Function Without a Chatbot

At Symisc Systems, PixLab's parent company, we have taken on top engineering students from selective schools either remotely or on-site for their projets de fin d'études, or final-year projects. Some worked on embedded software in C/C++. Others worked on web development in vanilla JavaScript.

One striking pattern is how often even bright students struggle to write a complete, working function without returning to a chatbot for help.

Among the more than 20 students we observed, the tools in use were either ChatGPT or Z.ai's GLM models. Curiously, we did not see anyone using Anthropic's Claude. This was simply something we noticed while working with them, not a formal survey.

An assignment on our Think-Act Desktop Agent gives a good example of what concerned us.

A small dashboard task

A junior developer was asked to write an analytics function for the agent's internal usage dashboard. The task was to retrieve statistics stored as JSON in Redis through the backend and display them on the page using vanilla JavaScript.

He had a master's degree and was actively looking for a job.

During the implementation, he kept returning to his chatbot for elementary questions, including how to get an HTML element by its ID.

That meant looking up document.getElementById().

There is nothing wrong with forgetting a method name. We look things up every day, and using a chatbot for that is perfectly reasonable. What caught our attention was how much of the implementation depended on asking for the next step.

We expected him to need help with our codebase. But inspecting a JSON response, selecting an element and updating its contents should have been familiar enough for him to make progress independently.

Completing the assignment is only part of it

A student can follow a generated implementation and understand each line when it is explained. Writing a similar function from scratch can still be difficult.

The first attempt is where you have to make your own decisions. You inspect the input, decide what to do with it and discover what you misunderstood. Even a small function gives you practice that should make the next one easier.

When the chatbot supplies every step, it becomes harder to know how much of that practice is actually happening.

We build AI products ourselves. We see the usefulness of these tools, and there is no reason to ban them from an internship. But getting the work finished cannot be the only measure of a successful placement. The student should leave more capable than when they arrived.

A reasonable expectation

For a task like this, we think it is reasonable to ask a junior to make an initial attempt before requesting a generated solution. Read the documentation, inspect the response and try the implementation. Then use the chatbot to help with a specific difficulty.

Code review should include a conversation about the work. Ask the student to explain a condition, handle an empty response or make a small change. There is no need for a memory test or an interrogation.

A master's degree does not mean someone knows everything, and nobody expects a junior to work without help. But after implementing one dashboard function, they should be better equipped to write the next.

That is what we want to see: not whether they stop using the chatbot, but whether they need less guidance as they gain experience.

This is how we build our frontends

At PixLab, we use only vanilla JavaScript for frontend development. No React, no Vue. The same approach powers our customer dashboard, which serves thousands of customers, with a backend ingesting millions of real-time API usage records.

We had not removed a framework to make the assignment harder. He was working with the tools we use in production.

Customers rely on that dashboard to check usage for services such as our background removal API. Whether we are displaying those request counts or reviewing Think-Act activity internally, someone needs to understand how the data reaches the screen and why a number might be wrong.

That was the useful part of the assignment: following the data, writing the function and checking its behavior. It was also an opportunity to become comfortable with basic browser development.

UnQLite Embedded Database Engine v1.2.1 Released: Faster, Lighter, More Reliable

UnQLite

Symisc Systems is pleased to announce the immediate availability of UnQLite v1.2.1 – the latest stable release of the embedded NoSQL database engine.

What’s New

  • Performance Boost – Up to 30% faster on key-value operations and document store queries.
  • Reduced Memory Footprint – Optimized KV store engine lowers RAM usage by an average of 15%.
  • New API: unqlite_kv_append() – Append binary data to existing keys without reading the whole value.
  • Improved JSON Validation – Stricter schema checks when using the document store API.
  • Bug Fixes – Addressed race conditions on concurrent reads in WAL mode and corrected cursor behavior after rollback.

Upgrading

UnQLite v1.2.1 is a drop-in replacement for v1.1.x. Simply drop the amalgamation build on your source tree and you are done. No further action are needed.

Full release notes are available on GitHub.

Why UnQLite?

For those new to the project: UnQLite is a self-contained, serverless NoSQL database that stores both key/value pairs and JSON documents. It runs in-process with zero configuration – ideal for mobile apps, IoT devices, and edge computing.

Get Involved

Upgrade today and let us know what you build with UnQLite!