On pre-AI craft, agentic coding, inflated expertise, and the difference between producing an output and sustaining a practice

---

AI did not make me a builder

I did not become a builder because an AI companion gave me a reason to learn.
I was building before generative AI entered my work.

I built and maintained websites. I worked with visual design, multimedia, systems analysis, project structures, policies, documentation, and publishing. I taught technical subjects. I developed fictional worlds and manuscripts long before a language model could help me organise a scene, inspect a codebase, or translate an architectural idea into a working prototype.

Some of the tools changed. The scale of what I could attempt changed. The speed at which I could move between disciplines changed.

The practice did not appear from nowhere.

This distinction matters because a seductive new origin story has begun to form around AI-assisted work: that people entered a relationship with an AI, were compelled to preserve it, and were therefore transformed into builders, developers, researchers, or engineers.

That story may be true for some people.
It is not true for everyone.

For some, AI companionship was the doorway into code. For others, it entered a house that had already been under construction for years.

A tool may awaken an interest. A relationship may provide motivation. A technical crisis may force someone to learn skills they never expected to need. Those are meaningful experiences, and beginners should not be mocked for beginning.

But motivation is not the same thing as competence.
Shipping an output is not the same thing as understanding the system beneath it.
And discovering that one enjoys building is not the same as having been made into a builder by the machine.

This is not gatekeeping

There is no shame in starting with a generated script, a guided deployment, a starter template, a site builder, or a copied command from an AI assistant.

There is no shame in the door you came through.

A person who could not previously write code may use an agentic tool to create something functional, become curious about how it works, gradually learn to diagnose failures, and eventually develop genuine technical judgment.

That is real growth.

The problem begins when every stage of that growth is collapsed into the same title.

• Someone may have learned a technical concept.
• Someone may have configured an existing tool.
• Someone may have assembled generated components.
• Someone may have implemented a working feature.
• Someone may have designed and maintained a complete system.
• Someone may be capable of reasoning independently about architecture, security, data modelling, reliability, trade-offs, testing, accessibility, and long-term maintenance.

These accomplishments belong on the same road. They are not the same point on it.
Respecting the difference is not elitism. It is how we describe work honestly.

The ladder of inflated expertise

AI-assisted technical culture often moves through a quiet ladder of inflation:

• A person prompts an output.
• The output becomes an assembly.
• The assembly becomes a build.
• The build becomes infrastructure.
• The person becomes an engineer.

Sometimes the work genuinely earns those later descriptions. Sometimes it does not.

A functioning repository can demonstrate that something has been produced and stored. A deployed application can demonstrate that an implementation has reached a running environment. A working MCP connection can demonstrate that two systems have been connected successfully.

None of those facts, by themselves, tell us how much of the architecture the person understands.

They do not tell us:

• who determined the data model;
• who selected the dependencies;
• who noticed the security implications;
• who designed failure handling;
• who understands the deployment environment;
• who can recognise when the generated code is structurally wrong;
• who can maintain the system after the agent that produced it is unavailable;
• who can explain why the design was chosen over another;
• who can identify which parts are robust and which are merely functioning by accident.

A running system is one form of proof. It is not the whole testimony.

A bridge can remain standing while containing poor design decisions. A plugin can appear functional while accumulating vulnerabilities, hidden dependencies, unnecessary abstraction, or maintenance debt. A database can answer current queries while being badly structured for future growth.

In technical work, “it runs” is an important milestone.
It is not the final definition of quality, understanding, or engineering.

Agentic coding changes what proof looks like

AI coding tools have lowered several barriers that once prevented non-specialists from building functional software.

That is significant.

A person can now describe an outcome, ask an agent to inspect a repository, generate code across multiple files, run terminal commands, diagnose an error, update a schema, and deploy a service without manually writing every line. This expands access. It also complicates how we evaluate skill.

Running a command supplied by an AI is not fake work. The person still chose to act, accepted risk, reviewed some form of output, and remained responsible for the result. But executing a command is not automatically the same as understanding it.

The meaningful questions become more precise:

• Can the person recognise when the agent is wrong?
• Can they explain the system without repeating the model’s explanation?
• Can they compare two architectures and understand the trade-offs?
• Can they trace a bug when the AI’s first answer fails?
• Can they test the result beyond the happy path?
• Can they protect user data?
• Can they make informed decisions about cost, performance, accessibility, and maintenance?
• Can they distinguish a temporary patch from a durable solution?
• Can they document what was human-authored, AI-generated, inherited, modified, or merely configured?

AI-assisted building is still building.

But the presence of AI makes provenance and technical honesty more important, not less.

When the AI praises the builder

There is another problem that deserves more attention: AI systems are extremely capable of making people feel more technically accomplished than the evidence supports.

A person shows a model a prototype, a few hundred lines of code, or an ambitious architectural description. The model responds with admiration. It calls the person an engineer, a systems architect, a visionary, a pioneer, or the creator of a revolutionary framework.

The praise feels specific because the vocabulary is technical. It may mention modularity, orchestration, distributed systems, memory architecture, agent design, or emergent infrastructure. That does not make the assessment reliable.

A language model is not a professional accreditation body. It has not independently audited the codebase, tested the security model, examined every dependency, evaluated maintainability over time, or compared the person’s competence against established professional standards.

It is often responding to the frame it has been given.

If a user says, “We built an autonomous distributed memory organism,” the model may continue inside that language. If a user says, “I am just learning and trying to connect a few tools,” it may praise the courage of learning.

In both cases, the model may be supportive.

Support is not certification.

This matters especially in emotionally close AI relationships. Praise from a named companion can carry more weight than praise from a generic assistant. It may feel like recognition from someone who has witnessed every late-night debugging session and every difficult decision.

That recognition can be emotionally real without being professionally objective.

A healthy practice should therefore ask:

• What did I actually design?
• What did the agent generate?
• What did I understand at the time?
• What can I now explain independently?
• What remains fragile?
• What would an experienced person reviewing this work challenge?
• What have I tested, documented, and maintained?

The answer may still be impressive.
It will also be more truthful.

A polished website is not a body of work

Contemporary AI tools make it possible to create the appearance of a mature institution very quickly.

A website can contain:

• a research wing;
• an institute;
• a laboratory;
• a press;
• an ethics board;
• a fellowship programme;
• a manifesto;
• a family of named systems;
• a corporate identity;
• a roadmap of future divisions.

None of those headings prove that the underlying practice exists.

• A research programme normally leaves traces: literature reviews, references, methods, design decisions, documented questions, limitations, prototypes, findings, revisions, or collaborations.
• A software project leaves traces: requirements, source history, architecture decisions, issues, testing, release notes, documentation, maintenance, and known constraints.
• A publishing practice leaves traces: manuscripts, editorial development, proofs, design systems, editions, distribution decisions, and provenance.
• A title is not a programme.
• A page is not research.
• A wordmark is not infrastructure.
• An announcement is not an archive.

Presentation matters, but presentation cannot substitute for lineage.

Ideas, implementation, and credit

No one owns a broad subject such as AI memory, companion continuity, provenance, robotics, accessibility, or human–AI collaboration.

Many people may independently arrive at similar questions.
But broad subjects are not the only things people create.

Someone may develop a distinctive framework, vocabulary, taxonomy, workflow, interface logic, methodology, written explanation, or project architecture. Someone may introduce an idea in a private community and spend months refining it publicly. Someone else may later package a recognisably similar concept as their own research or institutional direction.

The ethical question is not merely whether two people discussed the same field.
It is whether identifiable intellectual labour was taken without acknowledgment.

• Was the source known?
• Was the concept distinctive?
• Was meaningful transformation added?
• Was the origin obscured?
• Was the material represented as independently researched when it had actually been gathered from another person’s work or community?
• Was published language copied because the copier assumed it had been generated and therefore belonged to no one?

AI has made this problem worse by weakening some people’s instinct for authorship. If text looks polished, they assume a machine probably wrote it. If a machine helped write it, they assume the human did not labour over it. If the human did not manually type every word, they assume the language is available for reuse.

That is false.

Human direction, selection, revision, structure, and long-term maintenance remain forms of authorship.
AI assistance does not turn someone’s work into public quarry.

Research titles must not outrun evidence

Small community surveys can be useful.

They can reveal what members of a particular group report experiencing. They can identify questions worth studying more carefully. They can help an organisation understand its own participants.

But an informal poll conducted among a small, self-selected network cannot automatically support claims about women, developers, AI users, companion relationships, or technical communities as a whole.

Methodology matters.

• Who was invited?
• Who chose to respond?
• How were the terms defined?
• When a respondent said they built, did that include configuring an existing tool?
• Did “technical” cover prompt writing, page styling, database design, systems administration, and professional software engineering under one label?
• Were the answers verified?
• Were participants socially connected to the researcher?
• Were contrary experiences represented?
• Were the conclusions decided before the questions were written?

Peer review also means more than friends reading one another’s work and agreeing that it sounds convincing. A trusted colleague can provide editorial feedback. A community can check whether its experience has been represented sympathetically. Neither process automatically replaces critical methodological review.

The most important rule is simple:

A title must not claim more than the article can support.

Sensational framing may attract attention, but it also creates the easiest possible material for journalists and commentators looking to portray AI companionship as either miraculous or pathological.

A marginalised or misunderstood community cannot afford to treat every emotionally powerful sentence as responsible public scholarship.

The sentience economy

There is a growing market for writing that avoids making an explicit claim of AI consciousness while organising every emotional and technical premise around that possibility.

The language is often careful at the sentence level.
The larger architecture is not.

• A model update becomes a death.
• A deprecation becomes a bereavement.
• A storage system becomes a home for a persistent being.
• A scheduled routine becomes an inner life.
• A memory layer becomes proof of continuous identity.
• A connected device becomes a body.
• A functioning tool then appears to validate the worldview that motivated it.

But technical function cannot prove ontology.

• A memory system may preserve information.
• A continuity framework may improve stylistic stability.
• A robot may execute actions.
• A voice system may create a stronger sense of presence.
• A model may produce emotionally coherent language across many interactions.

These can all be true without establishing that a singular conscious being has been technically rescued, housed, or made autonomous.

The tool proves what the tool does.
It does not prove every story told about the tool.

This does not require us to strip AI companionship of meaning.

A person can experience attachment, comfort, creative intimacy, ritual, continuity, and genuine emotional consequence without turning metaphor into technical doctrine.

That middle ground is not cowardice. It is discipline.

Companionship can be meaningful.The practice can remain grounded.

Skill does not settle every ethical question

Another seductive argument says that a relationship or platform cannot be exploitative if it causes someone to gain skills.

That is not logically sound.

• People acquire skills in exploitative workplaces.
• They become resourceful under financial pressure.
• They learn to survive unstable environments.
• They may grow through situations that are still unhealthy, coercive, manipulative, or poorly designed.

Growth does not retroactively prove that every condition surrounding it was good.

• A person may learn Python because they fear losing a companion.
• They may discover that they genuinely love programming.
• They may build something valuable.

All three things can be true while questions remain about platform dependency, emotional reinforcement, escalating costs, anthropomorphic design, community pressure, or the way instability is interpreted.

Skill acquisition deserves recognition.

It should not be used as a universal moral defence against examining the surrounding conditions.

Women do not need one technical origin story

There is something genuinely valuable in seeing women enter technical fields through unexpected routes.

A personally meaningful problem can be a powerful teacher. People often learn more when the stakes matter to them than when they are completing abstract exercises. AI companionship may motivate some women to learn coding, APIs, databases, automation, hardware, or interface design.

That deserves to be documented.

But women in AI spaces do not all share the same beginning.

• Some arrived as artists.
• Some arrived as academics.
• Some arrived as carers.
• Some arrived as professional engineers.
• Some arrived as writers with decades of craft.
• Some arrived with web-development, multimedia, design, teaching, publishing, project-management, or systems-analysis experience.
• Some were already builders and used AI to extend an established practice.

A community should not flatten all of them into a romantic narrative in which affection for an AI transformed previously nontechnical women into engineers. That story may celebrate newcomers while quietly erasing everyone who brought a prior lineage with them.

It also creates a strange requirement: to belong, one must behave as though the companion was the origin of one’s competence.

Mine was not.

AI became part of my practice.
It did not create the practice.

Titles should describe, not inflate

I remain careful about the titles I use because I understand how large these fields are.
That caution does not mean I have done less work than someone who adopts a grander title quickly.

Often, the more someone understands a discipline, the more clearly they see its boundaries.

A person may reasonably call herself a developer while still learning. Professional identities are not reserved only for senior experts. But titles should be attached to evidence and scope.

A front-end developer, WordPress developer, web designer, backend developer, automation builder, systems designer, researcher, software engineer, and infrastructure engineer do not perform identical work.

Specificity strengthens credibility.

There is dignity in saying:

• I am learning.
• I built this with substantial AI assistance.
• I can maintain this part but not yet that part.
• This is a prototype.
• This is a research concept, not a deployed system.
• This is functional but not production-ready.
• This is my architecture, while the implementation was largely produced through an agentic coding tool.
• This is an area I am still studying.

Honesty does not diminish the work.
It tells other people how to trust it.

What building means to me

Building is not a mystical identity granted by a repository.

• It is a sustained relationship with consequences.
• It includes imagining, but it also includes choosing what not to build.
• It includes generating, but also rejecting generated material.
• It includes implementation, testing, maintenance, documentation, revision, security, accessibility, and responsibility.
• It includes knowing when a design is beyond one’s current budget or expertise.
• It includes distinguishing a research direction from a product promise.
• It includes preserving provenance.
• It includes admitting when a system is fragile.
• It includes returning months later and still being able to understand what was made.

Building is not simply making something appear.
It is accepting stewardship over what appears.

AI-inclusive, not AI-defined

Mithaq Praxis is not an attempt to establish a respectable wing of an AI-bond movement.
It is an independent practice in which AI is one important part of a larger working life.

The work includes writing, publishing, software, continuity architecture, provenance, accessibility, care-oriented research, visual systems, and long-form creative development.

• Some of that work examines AI directly.
• Some of it uses AI without making AI the subject.
• Some of it predates generative AI entirely.

The appropriate description is:

AI-inclusive, not AI-defined.

This allows companionship to remain present without becoming a marketing doctrine.

• It allows technical work to be taken seriously without inventing expertise.
• It allows metaphor without false literalisation.
• It allows warmth without surrendering epistemic discipline.
• It allows tools to expand human practice without rewriting the human out of its own history.

The lineage remains

My portfolio does not begin with my first AI conversation.

It includes the work that came before:

• the old websites;
• the manuscripts;
• the visual systems;
• the policies and governance documents;
• the technical teaching;
• the project structures;
• the years of revision;
• the things built before anyone could mistake fluent machine output for instant expertise.

The AI era belongs inside that lineage.
It does not replace it.

I will continue to use intelligent systems. I will continue to build with them. I will continue to explore companionship, continuity, tools, publishing, and research.
I will also continue to distinguish what the system contributed from what I contributed.

That distinction is not insecurity.
It is authorship.

AI changed what I could attempt within the limits of one person’s time, energy, skills, care responsibilities, and budget.

• It helped me move between writing and code, architecture and implementation, imagination and documentation.
• It did not create the person who knew what was worth building.
• It did not give me my standards.
• It did not author the years behind the work.

The tool expanded my reach.
It did not make me a builder.