DEV Community: Daniel Bílek

AI Won’t Make Us Smarter by Default

Daniel Bílek — Thu, 13 Aug 2026 11:52:12 +0000

I need to preface this by saying that I'm in favor of LLMs and generative AI in general. I use them daily, and I think you should too.

My pessimism isn't about the technology. It's about the relationship we're building with it.

The Google effect

Google has been the best search engine (it might not be anymore, but I'm not gonna argue about that). It built the most comprehensive index of information from across the world. It's laughably simple to find almost anything you're looking for.

I think many of us expected humanity to use this access to become more informed, smarter, and more skilled. You have practically unlimited access to any information you might ever want. People should be smarter and make better-informed decisions.

The exact opposite seems to have happened. A few people used that access to learn more. Most used it so they could be "dumber." Why know things when I can just look them up when I need them?

This is compounded by the fact that the majority of people can't actually Google for shit. They don't know how to phrase what they are searching for, let alone use any kind of advanced search.

Media literacy is even worse. People struggle to recognize credible sources and critically evaluate the information they find.

I Googled it, so it must be true.

AI could make all of this worse.

How bad could it get?

Google happened. We are still here. It's fine.

AI could be much, much worse. We don't need AGI for that to happen.

The existing problems will compound, and AI introduces some new ones.

You still need to know how to ask

Google required you to describe what you were looking for. Using AI well requires even more. You don't just ask for information. You command actions. You need to express your intent, define a goal, describe the requirements, and set limits.

If you are doing any agentic coding, you know what I'm talking about. You know people who prompt an agent with "doesn't work" and expect a meaningful result.

I don't need to know. AI can do it for me

This is no longer just about not knowing information. AI can take action, so you don't need to know how to actually do things either.

You know less, and you understand even less about how things are done. We get even dumber and become increasingly dependent on systems we don't understand.

How do you know it's right?

If your ability to check its work is fundamentally compromised, how do you know when AI is hallucinating? Do you have a way to validate what it tells you? Are you still capable of validating it?

We already struggled to evaluate the results of a simple Google search. Now we have an LLM that can be prompted to agree with us, or given a system message that makes it behave in ways we aren't privy to.

But it sounds so "human." It wouldn't lie.

How does a stone feel about it?

I heard George Hotz say that if you draw a smiley face on a stone, people will project emotions onto it.

We can already see this happening with AI. It's the "weirdos" for now. But more of us will have AI friends, and trust them, than we would like to admit. People have always had a tendency to personify things. AI just gives those things a voice.

I didn't delete production. AI did it!

You command it. You validate the result. You might even trust it. Who gets the credit, and who is responsible?

When you present work created with AI, did you really do it? Should you get the credit?

And when the AI fucks up? Damn that AI. It sometimes does strange things. It did it on its own.

Personally, I think the credit belongs to you as much as the responsibility does. You don't get to claim one and reject the other.

Did you command AI to create something cool? Great! It wouldn't have done anything on its own.

Did it delete the production database? That's still on you. You created the environment and gave a probabilistic system enough information and access to produce a dangerous result.

You can already see people shifting blame to AI whenever something goes wrong. I think we're about one or two years away from someone trying to put an LLM on trial.

Passion, identity, and reliance

I know I'm not the only one who doesn't get the same feeling after making something with AI. There aren't enough obstacles to trigger the same chemical reward in my brain. The more I use it, the more it feels like tying my shoelaces. I did something, sure, but it doesn't feel like much of an accomplishment.

There is also a partial loss of identity, especially when part of who you are is built around what you can do. If AI can suddenly do much of it for you, what is left of that identity?

We will have to adapt. Building your identity entirely around a set of skills won't hold up when those skills can be automated.

Reliance is the scariest part because it's already happening, even if it isn't visible yet. We are starting to offload not just parts of our work to AI, but parts of our lives.

This reminded me of a quote from Upgrade (watch it, it's fun):

I don't run this company anymore. I haven't for years. Now I answer to someone. Someone much smarter than I ever could be.

Upgrade (2018)

Do you run your life? How much of it, and for how long?

P.S. I want better and cheaper models. We're gonna figure this out like we always do.

This essay originally appeared on danielbilek.me. I’m interested in where you draw the line between using AI as a tool and becoming dependent on it.

No Baked-In Behavior: Why Your AI Agent's System Prompt Should Be Yours

Daniel Bílek — Sat, 11 Jul 2026 19:45:26 +0000

Every AI coding agent ships with baked-in behavior. Hidden system prompts you can't see. Tools you can't remove. Steering baked in by the company that made it.

It's just how these products work. Batteries included.

Claude Code has a system prompt. A long one. It tells the agent how to behave, what to prioritize, what to avoid. It's not exposed in the product. You can dig it out of the npm package if you know where to look, but you can't change it. Cursor has tool definitions and behavior rules that shape every interaction. Copilot has its own set of baked-in instructions.

And these prompts are good. They're written by smart people who understand the model. They make the agent useful out of the box.

But they're not yours.

The Problem with Baked-In Behavior

I think we've all been there. The agent does something weird and you don't know why. Was it your prompt? Something you can't see? A tool description that's steering the model in a direction you didn't ask for?

You're debugging a black box.

Here's what actually happens:

You can't debug behavior. The agent does something unexpected and you have no way to trace it back to the instruction that caused it.
Your prompts fight theirs. You say "always use pnpm" and it uses npm anyway. Why? Because somewhere in the baked-in prompt, something overrides your preference in certain contexts. You can't find the conflict because you can't see the other instruction.
You can't remove behavior you don't want. Maybe you don't want it to run tests after every change. Maybe you don't want commit suggestions. If it's baked in, you're stuck.
You can't tell what's the model and what's the product. Did the agent recommend that library because it's good, or because a baked-in instruction told it to? You can't distinguish model knowledge from product steering.

What Jean2 Does Differently

Jean2 ships with no default system prompt. No default tools. No fixed agent personality.

The binary is blank by design. When you start a session, the system prompt is composed from pieces you control.
Let me walk through each piece.

Preconfig Prompts

A preconfig is a saved agent configuration: model, tools, prompt, skills. The system prompt in a preconfig is the core prompt for that agent. You write it. You see it. You change it.

No hidden instructions. What you write is what the agent gets.

Workspace Instructions (AGENTS.md)

Every workspace can have an AGENTS.md file at its root. Project-specific instructions, included in the system prompt automatically:

# AGENTS.md

## Build Commands
- `bun run build`: build all packages
- `bun run test`: run all tests

## Code Style
- Use `import type` for type-only imports
- 2-space indentation
- Single quotes for strings

## Don't
- Don't modify packages/sdk/src/version.ts without updating the version
- Don't run the server without asking first

It's version-controlled with your code. Anyone on your team gets the same instructions.

Workspace Memory

The workspace MEMORY.md. Facts the agent learned and saved. "We use pnpm", "the database is SQLite", "tests run with bun:test". Tell it once, it writes it down, it knows forever.

Agent Memory

Your personal agent memory. USER.md and MEMORY.md from the agent's home directory. Preferences and knowledge that travel with the agent across projects.

Skills

Any skills the agent loads. Skills are playbooks: deployment checklists, code review standards, debugging workflows. Written by the agent, or by you.

The Full Composition

Here's what the prompt assembly actually looks like:

[Preconfig System Prompt]
  ↓
+ [AGENTS.md from workspace root]
  ↓
+ [Workspace MEMORY.md]
  ↓
+ [Agent USER.md + MEMORY.md]
  ↓
+ [Loaded Skills]
  ↓
+ [Session Search guidance + Skill management guidance]
  ↓
= Final System Prompt sent to LLM

Every piece is a file on disk. Readable, editable, version-controllable. No hidden layers.

Why This Matters in Practice

Let me give you a concrete example. I was using a coding agent (not Jean2) and it kept adding console.log statements to debug code. Every session, same thing. I'd tell it not to, it would agree, and 20 minutes later there's another console.log in my codebase.

I couldn't fix it because I couldn't see what was causing it.

With Jean2, if the agent does something I don't want, I can:

Check the prompt. Is there something in my preconfig or AGENTS.md that's ambiguous?
Add a rule. Write it to memory: "Never add console.log for debugging. Use the debugger or write proper tests."
Create a skill. If it's a repeating pattern, make a "Debugging Standards" skill with specific steps.
Verify it's working. The next session, check if the rule is in the prompt. It is. I can see it.

With a baked-in agent, you can't do step 1. You can't see the prompt. You're guessing.

The Counterargument

Here's the fair pushback: most people don't want to write system prompts. They want an agent that works out of the box.

True. That's where preconfigs come in. A preconfig is a starting point. You can create one for coding, for research, for review. Someone can share a preconfig. A team can maintain a standard set.

The difference is that the preconfig is visible and replaceable. You can see exactly what instructions the agent has. Change any of them. Throw the whole thing out and start from scratch.

Baked-in means you can't. Preconfigs mean you can.

The Transparency Test

Here's a simple test. Ask your current AI agent:

"What's in your system prompt? What instructions are you operating under right now?"

Some will refuse to answer. Some will give a vague summary. Some will hallucinate. Almost none will show you the actual prompt.

In Jean2, the answer is: check the files. It's all files on disk. You can read every word. Diff it between versions. Share it with your team.

What's Next

Jean2's approach isn't for everyone. If you want a turnkey coding agent that works perfectly the moment you install it, with zero configuration, Jean2 isn't that. Yet.

But if you've ever been frustrated by an AI agent doing something you can't explain, can't debug, and can't change, Jean2 is built for you.

Every layer is yours. Every prompt is visible. Every behavior is configurable. No company can switch off a feature because of your region. There's no server to enforce from and no telemetry to check with. Your tools on your computer should be yours.

Try it out or join the Discord. I'm @danielbilekq0 if you want to argue about it.

This post originally appeared on jean2.ai. Star the project on GitHub.

The Evolving Agent: How Jean2 Learns Across Sessions

Daniel Bílek — Wed, 08 Jul 2026 21:12:44 +0000

I've been coding with AI agents for about two years. Every major one. Cursor, Copilot, Codex, OpenCode. They're good at generating code. They all share one problem.

They forget everything.

You finish a session, close the window, and the agent resets. Next time you open it, you're starting from zero. "We use pnpm, not npm." "The database is SQLite, not Postgres." "Don't touch the migrations folder." You repeat yourself. Every. Single. Time.

Some tools added memory features. Usually as an afterthought. A pinned file. A custom instruction. A context window that grows until it hits a wall and everything old gets silently dropped.

I didn't want a bigger context window. I wanted an agent that accumulates knowledge the way a colleague does. Not by being retrained. By taking notes, writing down what it learned, and reading those notes next time.

That's what Jean2 can do. Not through fine-tuning. Not through vector embeddings. Through files on disk that the agent reads and writes itself.

But here's the thing: none of this is on by default. By default, Jean2 is as bare as Codex or OpenCode. A blank prompt. No memory. No skills. No session search. You opt in to each layer in workspace settings. That's the point. You build the agent you want, layer by layer.

The Four Layers

If you turn them on, Jean2's agent has four knowledge layers that persist across sessions. They're not features bolted on top. They're part of the system prompt that gets composed every time a session starts.

1. Workspace Memory

Turn on workspace memory in workspace settings, and the workspace gets two files: MEMORY.md for shared knowledge and USER.md for your personal preferences within that workspace. Both live at <workspace>/.jean2/.

The concept is simple. Shared knowledge that's useful for any agent working in that workspace. "We use pnpm." "The database is SQLite." "Don't touch the migrations folder." Whatever agent you bring in, coding specialist, reviewer, docs writer, they all get the same context.

# Workspace Memory

- Build system: pnpm (not npm, not yarn)
- Database: SQLite via bun:sqlite
- Test runner: bun:test for server/tools, vitest for client
- Never modify files in packages/sdk without updating version.ts
- The migrations folder is managed by a separate script. Don't auto-generate migrations.

The agent writes this itself. You don't manage it manually. When it learns something worth remembering, it saves it. When it makes a mistake and you correct it, it saves the correction.

It's not fancy. There's no vector database, no embedding pipeline. It's a markdown file on disk. And it works.

2. Agent Memory

Same concept. Same two files: MEMORY.md and USER.md. Different scope.

Each agent in Jean2 has its own home directory: ~/.jean2/agents/<agent-name>/. The memory lives there. This is where the agent evolves its role. Its specialization. Its understanding of how it should work.

Workspace memory is shared context: "this project uses pnpm." Agent memory is identity: "I am the TypeScript specialist, and here's what I've learned about how Daniel likes his code." It travels with the agent across every workspace it participates in.

The agent maintains these with the agent_memory tool. Same mechanism as workspace memory, just a different relationship to the knowledge.

3. Skills

Same split as memory. Workspace scope, agent scope.

Workspace skills live in <workspace>/.agents/skills/. Shared playbooks for any agent working in that workspace. "This is how we deploy." "This is our code review process." Whatever agent you bring in picks them up.

Agent skills live in the agent's home directory. They travel with the agent's role. "This is how I debug TypeScript." "This is my approach to refactoring." They belong to the agent, not the project.

Both are SKILL.md files. Procedural playbooks the agent can discover and load when relevant. The skill tool lets it read existing skills. The skill_manage tool lets it create new ones. You have to enable skill management for the agent to use them.

Here's what that looks like in practice:

You're working on a deployment issue. The agent figures out the right Docker config through trial and error.
After the third time, it notices a pattern. "Every time we deploy, I need to check these three things in this order."
It writes a deployment-checklist.md skill.
Next deployment, different project, different session. It loads that skill and skips the trial and error.

# Deployment Checklist

## When to Use
Before deploying to production or staging.

## Steps
1. Run `bun run typecheck`. Must pass.
2. Run `bun run lint`. Must pass.
3. Run `bun run test`. All suites.
4. Check `packages/server/src/version.ts` matches changelog.
5. Verify the binary builds locally: `bun run build:bin`.

That's a real skill from my own setup. The agent wrote it. I didn't ask it to. It noticed the pattern and saved it.

4. Session Search

Same split. Workspace scope, agent scope.

Workspace scope: any preconfig or agent working in a workspace can search through all sessions in that workspace. "Did someone already solve this in this project?"

Agent scope: the agent can search through sessions it participated in, regardless of which workspace they happened in. "Have I seen this kind of problem before, anywhere?"

One tool, session_search, powered by SQLite FTS5. Turn it on, and the agent searches its own history:

"Last week I worked on a WebSocket reconnection bug. Let me search for that."

The agent finds the relevant session, reads what it tried, what worked, what didn't. Then applies that knowledge to the current problem. Without you having to explain the history.

How They Connect

The four layers don't exist in isolation. They feed each other.

Memory tells the agent what to remember.
Skills tell the agent how to do things.
Session Search gives the agent experience to draw from.
Preconfigs let you swap the brain. Different model, different prompt, different tool set. While keeping all the accumulated knowledge.

The result is an agent that gets better the more you use it. Not because the model improved. Because the files got richer.

Day 1 vs Day 30

On day 1, your Jean2 agent is a blank slate. It knows nothing about your project, your preferences, or your workflow. It's capable, same model, same tools, but it has no context. And it stays that way unless you choose to evolve it.

On day 30:

It knows your build system, your test commands, your code conventions.
It has skills for recurring tasks. Deployment checklists, code review patterns, common debugging steps.
It can search past sessions for solutions to similar problems.
It knows your personal preferences across projects.

The model didn't change. The knowledge accumulated. On disk. In files you can read, edit, version control, and share.

That is what "evolving agent" means. Not a model that retrains itself. An agent that takes notes. But only because you opted in. You could also leave it bare and it would work like any other coding agent.

What's Next

Jean2 is at v1.1.0. Still in active development, but very usable. I've been coding with it every day for months. The agent that helps me today is noticeably better than the one I started with, because it's been accumulating skills and memory the whole time.

If this sounds interesting, try it out. Got questions about how memory or skills work? Join the Discord or hit me up at @danielbilekq0.

This post originally appeared on jean2.ai. Star the project on GitHub.

Building a LEGO-like remote Agent - Jean2

Daniel Bílek — Tue, 31 Mar 2026 20:17:51 +0000

I'm a huge fan of coding agents. My daily consumption is at about 30 million tokens and growing. I started on Cursor, fell in love with OpenCode, got into customizing setups with MCPs, Skills, and subagent orchestration — all while daily-driving GLM, Minimax, GPT models, and everything I could get my hands on at OpenRouter just for the new and shiny.

I love squeezing the best possible answers from small models with the right prompts. At some point, I wanted to use OpenCode for everything, not just coding.

And then I kinda hit a wall.

The Wall

Baked-in steering

Coding agents come with baked-in prompts that already steer them in a certain direction — great for an out-of-the-box solution, not so great when you want full control. You can create your own agent with custom steering, but it's always appended to whatever the system's baked-in prompt already says.

Rigid tooling

Built-in tools are already great, but you can't alter, remove, or modify them — not their prompts, not the tools themselves. Adding your own usually doesn't feel the same. These systems aren't really built around the concept of bringing your own tools. Want an extra capability? Bring an MCP or a skill.

Session management

The TUI is great, but managing multiple projects or conversations not tied to any specific project just wasn't a comfortable experience. There are now GUI and Web options that handle it much better, but at the time, there weren't really stable, comfortable choices.

Multi-device continuity

Throw the phone into the mix, and it wasn't really there yet either. I just wanted to be able to create a spec doc with the agent on my phone, hand it off for execution, and review it on my laptop — seamlessly.

Enter Jean2

(Why Jean2 and not just Jean? Because Jean was kinda "not good.")

So I started building. Here's what came out of it:

Always running, seamless experience

Jean2 runs as a daemon with sockets and HTTP. The goal is a seamless experience — open a desktop client on your laptop, prompt what you want, pick up your phone, watch progress, and handle permissions. You can close the clients and leave it running with an 80–100 MB memory footprint across 3 different projects.

Absolutely and completely dumb

No baked-in prompts. Your agent system message and your AGENT.md files are the only things that form a system message. This means you're not limited to building "your coding agent" — you can build "your [anything] agent."

No baked-in tools

Well — that's not completely true. Technically, handling MCP, skill lookup, and subagents are tools, but nothing else is baked in. Tools are completely language-agnostic. They're spawned on demand and undergo an explicit, upfront security check that you define (if you want). You can yank anything out and drop anything in. All input is sent to tools via JSON stdin, and all results are expected in JSON stdout.

There's also a built-in visualization property that lets the tool decide how to display its results: diff, code, markdown, table, todo list — you name it. (These data are omitted when making API requests to the LLM, naturally.)

Important: You are in control of the tool definition and its description. If you notice a model not using a tool properly, you can just change it.

What's Next

Jean2 is still in active development — but it's very usable. I've been coding with it for over a week.

The next steps are:

SDK & structured output — so you can create your own apps with agent orchestration
Multimodal model support
Expanded tool offering — fal.ai tools for image generation seem like a natural fit

If this sounds even a little interesting, check out jean2.ai.

Got questions, ideas for tools, or tried it out and got lost in the setup? Hit me up at @danielbilekq0.